Hi there!
I took some time to think about all the headwind that my idea got and I’m going to try to propose a compromise.
Immediate cure for future deprecations
I suggest that the fellows ensure that every dropped variable gets a system check. This check will be around for a couple of versions and is then removed. This will ensure that it’s visible to everyone and that bad things won’t happen to people like me.
I already talked to @sarahboyce about it and she seemed fine with it. Sarah, please correct me if I’m wrong here 
Maintenance support
I think it’s settled that we want to do something helpful.
It was agreed here initially that trying to do something was worthwhile: these kind of things come up almost every time we remove anything. It would be a long-term win if we were to find a good solution here.
I’m honestly not sure about this - IMHO academical issue - that people might use this one variable for different purposes. But since we’re not where we should be in terms of silencing system checks more precisely, I do see the concerns about “I have to silence everything when I only want to silence one thing.”
I agree with Carlton on having a permanent list of all the variables that were removed. It’s not that the fellows deprecate 200 variables per version. This list will grow very slowly and it could help quite a bunch of people.
Reading the PR: The list of removed settings isn’t uninteresting… […]
To bring together the points of a too broad system check and the wish to help the crowd more, I think I like Carltons idea of an optional check:
I wonder if running this only via a flag
--removals(similar to--deploy) which we’d do on upgrading resolves the issue? If the settings were grouped by release, I could pass a--since-versionoption to limit the check to just recent versions (after 4.2 if I’m updating from the LTS next April, say). (I guess I could maintain an--ignorelist if I had shadowed an old setting.)
IF I really am going crazy and reuse a bunch of old variables, at least it won’t be as intrusive as a system check that fires on every dev-server reload. On the other hand, it gives people like me a neat tool at hand when taking over maintaining old projects.
What’s the general feeling about that proposal? I’d be very happy to get this stuff in in 5.2 since it’s a LTS version and will therefore help a lot of people.
Best from Cologne
Ronny