As discussed on 15234, there is never a rush to remove Config parameters, and
it should only be done when there’s some clear value. Since the overhead of
having an unused parameter is ~zero, in my opinion this occurs only when we
really need the operator to consider the semantic impact of its de
15234 was a discussion about changing names and making parameters work
with the old ones. Still working parameters, backward compatibility and
not placeholders.
Benedict, I can understand that when I said removal in this ticket you
thought I will deprecate in Config but unfortunately it is not w
+1 on introducing compile time checks to ensure backward compatibility.
Confusion due to usage of deprecated settings is understandable. However,
settings marked deprecated should produce a warning in logs so that the
operators become aware of their usage in the YAML and can migrate to the newer
