LCD text uses read back of the destination, then blending of each glyph on to the destination.
For performance, the implementation copies the whole bounds of the node rather than on
a per glyph basis.
However its possible for glyphs to over-lap, in which case the blending of the 2nd of these
to be rendered to be against the *updated* destination, including the first glyph, otherwise
it will simply obliterate whatever part of the 1st glyph rendered into the overlapping rectangle.
The results are obviously bad. The JDK has handled this by detecting such over-lapping cases
in the rendering loop and doing a re-read as needed. 
The results are at best more fringing, and at worse obvious holes in glyphs.
The test case for RT-19024 using Futura Light shows this clearly between the "t" and "e" of "text".
If this is needed frequently, then the FX approach of copying all the node becomes far from optimal
as you are reading back a lot per-glyph. 
What's more since FX defaults to fractional metrics (sub-pixel positioning), then glyphs are more
likely to be placed close to each other.
Also is possible that non-adjacent glyphs in the sequence might overlap, so really you need
to check for overlap of a glyph with the accumulated bounds of the previous rendering.

The only other possible solution that occurs is that the rendering be to the same read-back buffer
so updates are implicit. This depends on being able to be sure of the order of processing by the
hardware pipeline/driver. This might mean flushes where overlaps are detected which means
we'd still need to check for over-laps even if we can avoid read backs.