The procedural roots and their organic growth are very obvious in some parts of the plugin, and maintainability costs are non-trivial in these areas due to inflexible code, unnecessary coupling, latent bugs, and pieces of logic that are hard to reason about. This makes it either very costly or not even directly feasible to work on major structural changes to open up new use cases.

Work needs to be done to intentionally design an architecture that is streamlined for the particularities of the plugin and that get rid of all the current major pain points of the code base.

The implementation can then proceed via the Strangler pattern, extracting one subsystem at a time and refactoring it into a separate (and completely uncoupled) component (to be done in separate Epics).