Should the `automatically_declare_parameters_from_overrides` node option be deprecated and removed?

As far as I understand, the automatically_declare_parameters_from_overrides node option was added during the Crystal->Dashing transition to allow users to keep using code written for Crystal without being forced to immediately migrate to the parameter declaration and description system added in Dashing.

I think that the intent back then was to eventually migrate all use of parameters to the declarative approach. I found some discussions like the one in #730 that refer to automatic declaration as something that should be avoided in all but a few niche situations. However, since the automatically_declare_parameters_from_overrides option has remained available in all releases since then, it's still possible to write code that uses it -- it's even tempting to do so, because the parameter declaration and description API is quite verbose and relying on automatic declaration requires less developer legwork.

This has left parameters in rclcpp in a messy situation because code written with the expectation that automatically_declare_parameters_from_overrides is enabled is not functionally compatible with code written for explicit parameter declaration:

• If automatically_declare_parameters_from_overrides == false, then getting the value of an undeclared parameter using get_parameter_or will always return the fallback value, even if YAML text containing a map of parameters has been passed to the node from the command line or in a launch file.
• If automatically_declare_parameters_from_overrides == true, then declaring a parameter when the value of that parameter is also set by passing YAML text to the node will throw an exception.

An example of a troublesome situation is if someone creates a class that gets parameters but does not declare them. If I want to include that class as a member of my own node class, then I am required to set automatically_declare_parameters_from_overrides to true in order to make that class work correctly, which then limits how I can use parameters within my own code.

Summarizing my questions for discussion:

• Is my understanding of the motivations behind all this correct?
• Should the migration to the parameter interface added in Dashing be completed by removing support for the previous interface?

Start by reviewing the Dashing release documentation and discussion #730 cited in the issue, then examine how automatically_declare_parameters_from_overrides interacts with get_parameter_or and explicit declarations. Done would require a resolved project decision on deprecation or removal, along with an agreed migration direction.