While in general I don't like any horizontal (plugin <==> plugin) interdependency, because that leads to self-contained breakage, it's true that we officially support it partially, and we do that more specifically, for installation and upgrade purposes, via $plugin->dependencies.

But we aren't really observing those dependencies dynamically (upgrade step by upgrade step), but statically (final versions vs final versions, not yet installed).

At the same point we insist keeping Moodle being upgradeable since 4y ago (Moodle 2.2.0) and it's really difficult to trace how database/apis were at that moment. IMO we should break really more frequently, but that's another story.

The point is that both those long upgrade paths and static dependencies checks can lead to problems like MDL-52291, where a change performed 2.5y ago (for Moodle 2.6.0) is preventing any people running older versions to upgrade to 3.0.

Of course, this can be workaround usually by upgrading to intermediate version and, from there to final one. But it's not the solution as far as we officially support 2.2 => 3.0.

This is about to perform some improvements to the installation and upgrade routines to achieve that.