Here's what this discussion makes me think of--RSS has a link element. That link was very generic, and has been variously used to link to what Atom calls link/@rel="alternate" and link/ @rel="related", and perhaps even other things. Once we'd gained a little experience and discovered that the imprecision of the meaning of the element was limiting uses we wanted to make of feeds, we created more specific types of links. Hopefully, we were specific enough this time that we won't run into significant use cases that we've rendered impossible, but who knows.
Now we're defining a method of navigating through a chain of linked documents. We know of two specific use cases that we're sure we want to be able to do: paging through things like search results, and catching up on incremental feeds (or reconstructing the entire state of the feed, which is an extension of catching up). It would appear that the same link relation can be used to do both of those things without the fear of conflict, because they operate within feeds that have a basic difference in nature, so they're unlikely to both be needed within one feed. Also, from a certain point of view, they are really the same thing--a way to navigate through the current state of the feed. The fact that incremental feeds don't have old states that have been discarded and replaced the way non-incremental feeds do (their former state gets augmented rather than being replaced) doesn't make a difference with respect to the issue of navigating through their current state.
So why don't we create a mechanism to do those two things (that are really one thing), and NOT make it generic enough to encompass other things that we might want to do someday, which might lead to the same sort of limitation that RSS has by only having one generic link element? Sure, we COULD do all of our interdocument navigation using "next" and "prev" until someday when we decide that we need something more specific for some of the navigation use cases. But then we'll be doing some of the same things multiple ways--some people sticking with "next" and "prev", and some using whatever new methods or link relations are invented, and nobody quite sure what "next" and "prev" mean in any particular feed. Why not wait till we've really figured out what other ways we might want to navigate between documents, and then devise a new method for doing it?
If we're going to create some generic link relations for people to experiment with, let's create somethings that's explicitly for doing experimental things with so that the link relations we want to do more specific things with aren't rendered less useful by the experimentation. Register "x-next" and "x-prev" or something for that, or register "next-page" and "prev-page" for the things we know we want to do. Or don't register any such thing--just don't promote use of the the link relations we define for (reasonably) well understood use cases to do experimental things.
We'll, I've spoken my mind plenty on this issue, so unless somebody brings up an issue that my opinion on couldn't be understood from what I've written already, I think I'll leave it at that. If we go with a highly-generic definition and it causes trouble down the road, I'll have some big ASCII art letters ready to say "I told you so". If not, then oops, I guess I was wrong.
