I would like to add my voice to the argument for not depending on other add-ons in almost all circumstances, and provide another example of why it seems unwise.
Add-ons by their nature, are more fluid and freely changed than NVDA core, with potentially less consideration given to changes that may not be compatible with previous add-on behavior. That seems doubly true for behind the scenes, implementation-specific details.
None of that is a bad thing, but it leads very quickly to not just depending on another add-on, but depending on a specific version thereof.
That could, if it becomes widespread, result in a complex web of dependencies, which NVDA is not currently equipped to manage. That will mean the user must manage it, which could lead to difficult situations.
Consider an update to add-on A, which depends on a newer version of add-on B. So the user updates add-on B.
However add-on C, which also depends on add-on B, requires an earlier version of B. Add-on C's developer is not answering his emails, or doesn't have time to update the add-on to account for some new API, and so C is not going to be updated.
But the user really depends on C. So she has now to find an older version of both B and A to install, in order to keep C happy.
That seems untenable to me.
For those reasons, I am opposed to the practice of having add-ons depending on each other.
For some few add-ons, it may be possible to include them as Git submodules, thereby allowing the includer to manage versioning of the inclusion; but most, if not the vast majority, of add-ons are not written with the idea that they might be depended upon by other add-ons, or included in them.
My two bits, for what their worth.