Public API evolution

When adding or changing parameters on a public API, make the change explicit, consistent, and backward compatible.

• Add new parameters as named, documented arguments instead of smuggling them through a generic **options dict. This keeps the signature self-documenting and lets the docstring describe the parameter properly, e.g. prefer add_url_rule(rule, endpoint, view_func, provide_automatic_options=None, **options) over options.pop('provide_automatic_options', ...).
• When a parameter is threaded through delegating or recorded calls (such as blueprint registration lambdas, decorators, or wrapper classes), make sure it is forwarded everywhere the original call is replayed, not just in the primary code path. A parameter that works on direct calls but is silently dropped on deferred/recorded calls is a latent bug.
• Preserve documented call contracts for methods meant to be overridden or dispatched to (e.g. View.dispatch_request(*args, **kwargs)). Don’t strip arguments from a default implementation just to “fix” a call site—update the implementation to accept what the public contract promises, and improve the error message instead.
• When generalizing or renaming a public method (e.g. from_json becoming a thin wrapper around a more general from_file), keep the old method working but emit a DeprecationWarning pointing to the replacement, and only remove it in a future major version.
• Where composition rules are ambiguous (e.g. combining a parent and child blueprint’s subdomain similar to how url_prefix is combined), pick the behavior consistent with existing, already-established composition patterns rather than introducing a new, surprising rule, and document the choice clearly.
• Resist adding configurability “just in case.” Extension points (such as JSONProvider) should stay minimal and cover proven use cases; push anything more specialized (custom mimetypes, object hooks, validation) to subclasses or external libraries rather than growing the base API’s surface.