I don't know anything about Debian's armhf plans except what they posted. Here is my understanding of the situation in the hopes it may be helpful (please correct me if I am mistaken).
I will also mention I am kind of hoping the Fedora RPi Remix will be ARMv6+hardfloat build as this link seems to indicate: http://www.cnx-software.com/20.....-remix-14/
If it is not, then it won't quite be fully "Raspberry Pi optimized" (yet). The performance difference depends on the applications use of floating point and how many times the floats are passed as parameters. The performance improvement can be worthwhile for many apps (see some other forum threads for examples).
However, from my understanding of ARMv6 vs ARMv7, I believe a fair amount of the Debian hardfloat work will be useful for the Raspberry Pi, but it will need some changes for these builds to work on RPi (i.e., recompile with different options at the minimum).
It looks like Debian-armhf is targeting armv7+vpf3-d16+Thumb-2 as their baseline. This will not be compatible with the RPi.
The differences between the ARMv6 and ARMv7 architectures are not "huge" (but there certainly are some instruction set differences).
The biggest feature that the RPi CPU is lacking is Thumb-2 support. The other thing is no NEON SIMD support but it looks like Debian-armhf isn't going to require NEON by default, so that is probably fine.
RPi does have thumb mode (16-bit instructions for smaller code, but not the much improved thumb2 armhf uses), but this mode will not work with hardfloat (to my understanding - since it can't directly access the FPU registers). Since the RPi has 32-bit memory (I believe) there is no huge reason to not always use 32-bit arm code instead of thumb (except for the most memory space constrained applications perhaps). I am not sure, but I believe hardfloat will either preclude using thumb mode (16-bit instructions) or maybe require parallel libraries for those applications. On the RPi where speed is likely to be a larger concern than code-size I don't see thumb making too much sense anyways (but as always it probably "depends").
The RPi FPU is VFPv2 and has 32 registers (up from the 16 minium assumed by Debian-armhf). So this should be fine except for a few missing instructions from VFPv3 (probably only an issue for assembly language code). See http://infocenter.arm.com/help.....dejjh.html
For most C/C++ applications they probably just need to be recompiled with different options for the RPi (for armv6-vfpv2). This can be a substantial task though for all the packages in a distribution (and fixing the inevitable build "hiccups").
Any ARM assembly language files that have already been converted to use the newer UAL assembly syntax should be able to be reassembled using arm (32-bit) instructions (but often some tweaks are needed). Any assembly code using non-ARMv6 features will need some attention.
I could also see there being issues if the Broadcom user-mode libraries can't be recompiled with a matching options (but a "shim" or wrapper could perhaps be used in the interm, however that is not ideal). Hopefully Broadcom could be coaxed to help produce compatible libraries.
Another concern, unless I am mistaken, this may make this a "custom" ARM dialect for just RPi and we may not be able to run "normal" arm5tel binaries (or maybe there is Linux "magic" for compatibility with multiple ABIs). This may not be a concern (and it is not like there won't be other RPi Linux versions to run these apps). Also, not positive but I think RPi armv6-hardfloat applications will probably be compatible with the normal armhf (because ARMv7 is backwards compatible to ARMv6). Obviously, RPi won't be compatible with the normal Debian-armhf apps either (or we wouldn't be having this conversation).
Since some of this work could be done on emulators (or other ARM systems), this may be a good thing to work on while we all await the "ding" from the oven (or doorbell) and our fresh Pi is ready.
Perhaps it is already underway somewhere?