Having looked supporting different formats for rendering to and sampling from, I'd like to share my observations.
Extensions are claimed that are not supported
On iOS the implementation claims to support OES_texture_float_linear but this does not actually work and it defaults (silently) to nearest.
Float16Array still does not exist
It's still a major pain to deal with generating data to upload to Half-Float textures because despite repeated prodding on the ECMA-ML as well as here, we still don't have a Float16Array.
Some implementations do not accept Uint16Array upload to half-float textures
Safari and iOS refuse to accept an array for texImage2D to upload to half-float textures. Even though it's now in the specification that this is permissible. We talked about this. It was agreed we would allow that.
Setting linear blending mode on textures that don't support it generates no error
The UA complains about an unrenderable texture when you draw sampling from it, so it knows that the blending mode isn't supported. But you can't get an error from it either at texParameter or draw*. This is extremely awkward, because apparently (see above) the linear extensions have no meaning whatsoever, so you have to actually draw to figure out if blending works and then readback the results. If you (the UA) already knows that linear doesn't work, please don't make developers integrate a unit test to figure it out?
The color_buffer extensions have no meaning
Platforms (such as Chrome) that support drawing to floating point textures do not expose these extensions, leaving you no choice but to getExtension it and then promptly ignore anything you got and test if you can actually construct an FBO that is indicated as valid and draw to it and then read the drawn texture (trough another FBO because see blow).
readPixels of floats may or may not work
Some platforms do not implement readPixels from a floating point texture. Some do. Because of that, you can't directly test some of the more interesting properties of floating point textures (such as blending, filtering, clamping, etc.) but you have to do it trough a proxy unsigned byte FBO because you can't rely on readPixels.
Some devices do not expose floating point textures even though they support them
For reasons that completely boggle me, the fairly new Samsung S7 (just a year old) which has perfectly fine and working support for a variety of floating point textures/operations do not expose that to WebGL (by some combination of unlucky ES config and whatnot). That's a fairly big problem. Because samsung devices are fairly popular, it means floating point support on mobiles is actually retrograde, mean reverting slowly back to somewhere anno 2012 or so.
The only qualifier I can find for the situation is miserable and utterly broken. It's hurting WebGL. It should be addressed. It should have been addressed long ago, and most of these things came up in the past years at one point or another. I don't understand why they are not addressed.