>I strongly believe infinite scrolling creates more problems than it solves //

It sure does when it's used inappropriately. But can you imagine Pinterest, say, without it?

Sure it sacrifices findability or reproducibility of a view in exchange for discoverability and presentation of new content but that sacrifice works - and IMO it can work for an archive.

Provided items of content can be found, can be tagged by users (bookmarks anyone?) then if you're targetting the presentation of continuously updated content sources infinite scroll is fine IMO.

Do you have a problem with HN because one can't link to a specific view of a list of stories? Or with Google because SERPs change? Or with your favourite blog because the front-page updates with each new post?

HN, Google SERP or blog frontpages are not archives.

1) I have nothing to do with Archive.org, I'm just speaking from a UX designer's perspective. "Designing around" constraints is something everyone involved in a site build does, from backend engineers to designers to front guys to DBAs. You're presented with a set of constraints, and you come up with solutions that fit those constraints. Nothing evil.

2) There's nothing inherently wrong with "consume, consume, consume". I don't think anyone in the world would argue that Pinterest is evil or bad. It's a site for consuming en masse, plain and simple, and an infinite scroll enhances the experience. Clicking "next" 50 times would significantly ruin the user experience on that (and similar) sites.

If you need to advance exactly 50 pages, the worst thing there is from a usability perspective is to press PageDown 50 times, instead of clicking 5 times with progressive pagination or inputing the number in other traditional designs.

pinterest, facebook or twitter are whole-content streams, that's why they benefit from infinite scroll.

All very true, but if you're serious about looking at every item that results from some search (because you're researching, not merely browsing), then you will use the advanced search interface to get a CSV file (or JSON, XML, HTML, or RSS, according to preference) which you can then work with entirely locally. You'll be able then to keep track of everything you do with every item in that list.