Sorry, didn't mean to imply that it doesn't mitigate the problem, it does but it can only mitigate it.
Whether that turns the situation into a manageable one or not would depend on circumstance.
There's several problems:
One, the module is doing something that isn't its advertised function and _really_ isn't neccessary to implement its core function.
Two, it's changing behaviour of the parent program, this is a bad thing to do even when it _is_ neccessary.
Three, it isn't clear in situations like the Moose one, just when to turn it off or on, consider the following sequence within a single scope:
You enable warnings/strict. You do some code. You turn off warnings/strict. You do some code. You use Moose. You do some code. You turn on warnings/strict again not realising Moose turned them on. You do some code. You turn Moose off.
What's the state of play now? Are warnings on or off? Is strict on or off?
That depends on the implementation of how Moose is tracking warnings/strict - is it reverting to what it saw when it started, or is it counting references? It gives different results depending on how they implemented it.
This is _entirely_ uneccessary and only obsfucates behaviour that _ought_ to be under the control of the programmer.
Only works per-process.
Most webservers are multiple processes with a limited lifetime (they often get killed after a fixed number of requests).
Then there's the issue that most large sites have a server farm too...
I don't think you've taken a controversial position at all there, you've hit the nail on the head.
Modules should stay the hell out of your namespace and application except to do the things you've actually asked them to do.
Warnings and logfiles: abso-bloody-lutely.
If you break something, you need to be told about it once, not 5 million times.
If someone else breaks something and doesn't pay attention that they're being told 5 million times, you don't want to find the 5 billion other messages first thing monday morning.
It's a horrible horrible mess, and anything that makes it worse needs stomping on fast.
Is there a reason for assuming all xt tests are "release tests"?
I'm currently looking at using "xt" for all "extra tests", with "xt/release" for release tests, and "xt/slow" for slow tests.
I'd want to run the release tests for both automated and release testing (as you've described), but I'd only ever want to run the slow tests if I'd explicitly asked for them.
Now I could put them in yet another top-level tests directory, but that's getting messy, I'd rather keep all the "extra tests" in the "extra tests" directory.
I could also add checks for AUTOMATED_TESTING and RELEASE_TESTING and so on to each test in the xt/slow directory, but that's adding still more boilerplate to each test file, with all the problems that cut-n-paste boilerplate code has.
Of course my current distros all use Module::Build so this doesn't directly effect me, but if a convention is established, it will effect me eventually. (And getting release-tests working "right" in xt under Module::Build is causing me enough grief that I'd like to switch if something offered me a better alternative.)
While it might not be the default behaviour, it would be good if there was the option to say "only these dirs of xt are release-tests, not the lot".