Silent DeprecationWarning suppression in imported modules

Managing deprecation alerts in a large codebase without flooding logs depends on the warnings module’s ordered filter list and each module’s __warningregistry__. The documented default filters ignore DeprecationWarning outside __main__, so third-party deprecations can remain silent unless a filter explicitly opts in. Even after inserting an always action at runtime, the registry may still suppress a warning that was already recorded at a given module and line number, meaning catch_warnings(record=True) does not necessarily re-enable repeat emission within the same process.

The effective policy is order-sensitive: startup flags and environment variables are applied before runtime filterwarnings or simplefilter calls, which insert at the front of the list. Because default filter lists and registry semantics have shifted across versions, the exact behavior for a target interpreter is not always obvious.

In Python 3.11 and later, does bypassing or clearing __warningregistry__ inside catch_warnings(record=True) reliably re-emit a previously suppressed warning, or does registry state persist across the context? How do runtime filter insertions interact with startup -W and PYTHONWARNINGS entries to determine the first matching action for DeprecationWarning raised in an imported module? Is the documented default ignore of DeprecationWarning outside __main__ still authoritative in current releases, or has the default filter list changed?