Agreed. This was relevant perhaps back when I raised it, but LAS seem to have clarified their position on CFML compat now.

The only possible residual area it might be appropriate is being able to toggle-off all the divergences from ColdFusion that Railo implemented (and that should be the default state),but that's a discussion that's been had and disagreed about elsewhere.

I think it would be better for Lucee's CFML implementation if it "strongly downplayed" Railo's former CFML divergences.

Given several recent discussions on the subject of feature toggles involving a number of people including the reporter @Adam Cameron, I am comfortable rejecting this.

The consensus in such discussions seemed to be very strongly that feature toggles work against portability since FOSS developers must either ensure their code works in every combination of such toggles (impractical) or they'll target the (current) default settings which means nearly all developers must leave the toggles in their default settings in order to use that FOSS!

The new Lucee Language is a good opportunity to clean up CFML language behavior, but adding knobs and dials to change CFML itself is not a good idea.

Im not commenting on isNull being right or wrong, but I would like to vote against a feature toggle system. I am against anything that causes code to work differently based on a setting, whether that is an administrator setting or application setting (although if there must be one, the application is the place for it!)

Feature compatibility things ("full null support" being something else that would fall in this bucket) should be broken in full point releases with adequate documentation, betas and warnings. Looking at a particular line of code and having to keep in mind all of the different switches that could possibly be affecting how it functions is a maintenance nightmare.

If it must be done, something like javascripts "strict mode" should be used - something that is available in the source file that the affected code is in.