Looking at the way things are going (data sources and display devices), I
think replacing 8 bit integers with floats is an inevitable move. It will
also be big: most scripts, filters and most other code will have to be
reviewed or rewritten, but most should be fairly straight forward. It will
absolutely need widespread suport within the developer community, and a
schedule to get everyone ready for a release date, but if begun soon after
the move to Gnome 2, Gimp with floats could be released about the same time
as the commercial projects release their float based programs, if not before.
As I see it, the main points are:

1) There are a number of new sources (scanners, digital cameras) which now
gather data with more than 8 bits of depth. Scanners have done this for a
few years, and cameras are going the same way. Currently, they output 8
bits per channel, but users want to manipulate more depth, and the demand
(driven by marketing) is only going to rise. For Gimp, deepening the
buffers is going to need much the same effort (APIs, core code, buffers,
etc) whether a move if made to 16 bits or floats. Floats, however, are more
future proof.

2) Integer internal formats make for a lot of quantisation noise. Now, I
admit it isn't very easy to see most of the time, but when enhancing an
image, looking for faint subtleties, this noise can intrude into the
visible. Furthermore, it adds up. Floats would mean much less noise, and
the noise would scale with the brightness of the pixel.

3) Microsoft have an internal policy of moving to floats for graphics.
Hardware manufacturers are heavily rumoured to be moving to floating
pixels. When this occurs, integer graphics are going to be seen as
yesterdays technology. The sooner Gimp starts floating, the better.

-1) The working storage is going to be big. 4 times current buffer sizes.
However, by the time the code is written, a gig of RAM will be $50-$100
(prices are already falling sharply again), and those who can't upgrade can
keep using integer intrenal representations.

-2) The code will run more slowly. This, again, is already being solved by
hardware advances, but floating filters will run even more slowly when
applied to an integer buffer. I expect legecy users would have to make do
with a smaller selection of filters or upgrade their machines.

-3) The change will need a *lot* of work auditing code and changing small
details here and there. Perl handles floats nicely, but there could be a
few gotchas lurking in the assumptions made by contributers.

-4) This is a big change. Very big. Without a consensus in favour, the move
would cause more harm than good. If some developers are not contributing,
or are late, it could badly damage the project and it's reputation.

Related ideas for consideration
* A strict policy of "If it can float it must". A new API would translate
integer data to float on transfer to a filter, and translate results back.
* move input/output filters API for photo file formats (like JPEG) to
float. This would simplify interfacing for all combinations of file color
depth and internal representation depth (at the cost of computation and
compatibility for integer-integer situations)
* Floats could be moved into GTK, although I suspect this could harm
portability.
* A new native float based file format
* suggest range 0..1 for normal brightness.