The problem isn't that developing against a rebasing tree is too difficult, because it's
generally not too hard to update things. The problem is that developing against a rebasing
tree generates a repository which isn't suitable for inclusion in the rebasing tree. That is,
following your instructions would be fine if -next weren't a useful tree to try to get your
stuff into, but the resulting repository isn't something that Stephen can pull into -next.
I suppose if you're targeting 2.6.n+3 (or later) for inclusion, you could develop against
-next, but that's sort of pessimistic. And I think that, if it makes sense to publish your
changes at all, it makes sense to have them in a state where they go against vanilla linus.
Also note that, if you develop against -next, either it doesn't matter, because you don't have
any interactions with other people's changes, or you're going to waste a lot of time when a
tree that you interact with gets some conflict and Stephen drops it (requiring you to resolve
a slew of conflicts) and then picks it up again the next day (requiring you to resolve the
same slew of conflicts the other way, back to essentially the state you had before). And that
applies to quilt as well; quilt will happily let the base change under it, but you'll have
days when your code won't work without a pile of fixups, and the "bug" it will be due to is
that some code that you now require is temporarily and intentionally missing.