Hence my suggestion "Perhaps by moving purposely incompatible code out into a separate module (which can be installed for Railo compatibility)."
This way one would have Railo compat and ColdFusion compat at the same time, plus following the "reference" implementation of CFML (ie: Adobe's). There's 100% overlap on those last two, but they're commenting on different aspects of the same thing
Also full-version releases of newly launched products (and let's see Lucee this way) should not really have a problem with breaking backwards compat. However I still maintain one should not do this, but to move the Railo-specific features out into the Railo compat module, as mentioned initially.
I don't think it's controversial at all: indeed it's almost a no-brainer: move that stuff out of CFML and into .lucee. If your position is to strive towards CFML compat, and have a different solution for experimenting with non-CFML features, then Lucee 5 (beta, remember) is percisely the time to stop putting off-piste CFML features into the CFML engine, and add it to .lucee. It has the dual benefit of making it seem like you're taking this "Compatibility with ColdFusion" thing seriously, but it gives a value-add to .lucee (which is pretty short of value-add right now).
What an excellent idea. I wish I had thought to suggest that. Oh, hang on...