flag day for 64-bit?

We've discussed before the issues for switching to 64-bit interfaces
with clean compatibility.  There is RPC compatibility so that new
servers work with old clients.  There is (optionally) client-side RPC
compatibility so that clients try new RPCs and fall back to old ones
when old servers don't grok the new ones, and do their own EOVERFLOW
diagnosis when given large values to send to old servers.  Then there
is ABI compatibility for libhurduser, for which I have previously
described some scheme for automating the use of symbol versions with
mig stubs that I don't really remember and am too lazy to go look up
(but which is probably not so hard to actually implement).  I'm not
sure whether we ever discussed the API (source) compatibility
question, which is to say the incompatible change of the arguments to
io_seek et al from off_t to loff_t, but perhaps we (rightly) decided
that would be just fine since compiler complaints at the recompile
would cite where to insert the `l's.

None of that is so hard to do, but a) man are we lazy, and b) it would
leave us with a bunch of compatibility baggage to have to decide
someday when to drop.

So ... what if we just punted all that and had a flag day? 
I've been inspired by our success at the Big Punt with the libio ABI.

I am pretty sure we (which is to say, Mark) did things right in libc
already so that Posixoid programs will see no ABI change and those
built with LFS will suddenly start working with big numbers.  i.e.,
dd, mke2fs, e2fck, etc should Just Start Working on large partitions.

That is, the flag day is only for the RPC interfaces and for the hurd
itself.  Just replace all off_t with loff_t in *.defs; we can bump the
soname of libhurduser since that seems proper.  For the hurd, changes
should be pretty much just the query-replace--or maybe we just start
compiling the hurd with -D_FILE_OFFSET_BITS=64 (but I'm guessing that
probably has more gotchas than it's worth).

The libc work will be the only thing of any substance, and that just
some cut & paste.  It's just replacing foo64 functions that do
overflow checks and call foo with foo functions that just call foo64.

Unless I'm overlooking something, we could hack this up in a day and
then throw into debian new libc and hurd packages requiring each other
and conflicting with older ones and that would be that and noone would
even notice the incompatibility go by.