To keep this thread on-track, allow me to throw out some ideas.
Don’t crash on deprecated configuration statements
Several times in the past we’ve seen phase-in for a breaking change where a warning will be thrown for several versions when a particular statement is encountered. Eventually, a release will be issued where the configuration is officially deprecated and Home Assistant will fail to load.
This may still be required for substantial changes to an individual component, but there are a whole lot of situations where a particular statement simply doesn’t make sense anymore due to other changes that were made in the component.
For example, the vizio component long ago had a problem where it would log spew due to the self-signed SSL cert used by Vizio. Instead of fixing the problem, a configuration value suppress_warning was added to the component that would simply silence these errors.
Later, the issue was resolved somehow and the suppress_warning statement was deprecated. Anyone who had implemented this workaround now had to go back and remove the workaround or Home Assistant wouldn’t load.
Maybe, instead of breaking Home Assistant, one could simply ignore the deprecated configuration statement, and possibly log an error somewhere to let the user know it was happening? This is done temporarily, why not just leave it this way so we don’t break things that have no bearing on the user’s configuration?
Obviously this does not fit all breaking changes, but addresses some subset that otherwise would require user attention.