bug#16282: revisit; reasoning for not using ENV vars to provide workarounds for POSIX limitations?

[Linda Walsh]

I didn't fully  understand the reasoning for not wanting ENV vars to override
unwanted behaviors.

Specifically, I'm thinking about "rm -fr .", but there are some others it could
apply to as well.

ENV vars are used to configure all sorta of GNU utils -- so why the reluctance
to do so in order to provide backwards compatibility in overcoming prescribed
limitations imposed by POSIX?

It's not like it's impossible to create ENV vars that are unlikely to collide 
with
normal ENV var usage, i.e. _rm::EXPERT=allow_dot[,..other features].

Adding colons to the middle of the env var, should both, prevent any accidental
setting/usage of such as well as making such overrides easy to find and filter
on (if all included '::' after the util name, for example and all started with 
_ --
they would tend to collate together and the '::' would likely be unique enough
to filter on in a grep'ing of the environment.

If the issue was accident setting or collision with other usage, something
like that would seem to address that problem.   If there are other issues,
I'm not aware of them...

Thanks for any input...