When scanning for legacy procedural hooks Drupal will now by default attribute hook functions to the current module and only check for other modules if the function does not start with the current module name.
In the vast majority of cases this will have no effect since this is by far the most common way hooks are implemented.
Previously, it attributed hook functions to the longest module name that it could match them against, this resulted in hooks incorrectly being attributed to submodules if a function name overlapped with that name.
E.g. if both paragraphs and paragraphs_library were installed and the former implemented pararaphs_library_info_alter.
Instead of the paragraphs module and library_info_alter hook Drupal would register it as the paragraphs_library module and info_alter hook.
One side effect of this change is that a parent module can no longer implement a hook on behalf of a submodule if the parent module name prefixes the submodule since the first check will always match.
Note: Implementing hooks for another module is discouraged and may be removed in the future. It is now possible for a module to implement a hook more than once with OOP hooks and #3524377: Allow to skip OOP hooks and services for modules that are not installed will allow to add a formal dependency on another module and register it conditionally.
