Yeah, removed that all from 8220, thought about it more and saw this ticket...
We do want to keep in mind though that from a user perspective, inputting '2.178734872984723984729387" as a float and getting back "2.17873477935791" are not equivalent. So whatever we do needs to take that into account. If we use the stored=docvalues approach, then they'd need a copyField with stored=true field if it was important to them.
The other thing I like about the stored=docvalues approach, existing schemas/applications continue to work exactly as they do now. Upgrading is not surprising. Users can selectively take advantage of this new capability.
I think it'd even work if a user changed an existing schema from stored=true to stored=docvalues and did not re-index. True, they'd be carrying around some useless data in the *.fdt files until it was merged away for updated docs, but as long as docValues=true was set in the original schema, it'd "do the expected thing".
I suppose the same functionality could come from a new parameter on a <field> definition like fl_from_dv=true but aside from the awkward name, I think this is harder to wrap your head around.
If you were willing to pay the "wasted disk space" penalty though, a separate parameter on the <field> to control where the "stored" value came from would allow one to switch back and forth without re-indexing. But to be clear, I don't think this is a good idea; using the stored=docvalues option forces a decision to be made up-front.