The strategy I take now when confronted with something like this (in internal codebases, since I don't work on standards) is to refactor the interior implementa

The strategy I take now when confronted with something like this (in internal codebases, since I don't work on standards) is to refactor the interior implementation to include a new module with a "now and later" view: it does not hinder existing behavior, and it decouples enough of the internals that a rewrite or a new system with similar behavior can reuse the module as-is with a modest amount of integration effort; sometimes a facade module is included to make highly abstracted internals easier to consume in the 80% case. For example, an audio API that has nitty-gritty details about formats and buffers, but also has a "load and play this sound file" easing facade. Starting at the rewrite tends to obscure the actual dependencies and enable second system effects: factoring out the module gives you an anchor to hang things off of, either in the form of a general-purpose abstraction or an implementation detail surfaced as an API. Subsequently, maintenance will tend towards accepting the module as-is, and the "rewrite" turns into a refactor that uses the same module in a new context.