Hm. I’m sorry, I’m a bit confused with your proposed feature request, perhaps because since I’m an amateur programmer, some of the things aren’t clear to me (hopefully, however, the Panic developers understood your issue!).
As far as I know, there is no way of ‘discovering tools’ in macOS, so to speak, since, AFAIK, there is no central registry for ‘tools’. There might be a central registry for applications — i.e. anything that is installed under /Applications or ~/Applications or, well, wherever Apple has designated a ‘standard’ folder for applications; there are a few deeply hidden inside /System/Applications/ etc… — but I’m not aware how that mechanism works.
But ‘tools’… well, command-line tools can be installed anywhere; macOS doesn’t place any ‘restrictions’ on where these are. Homebrew puts them under /usr/local/Cellar/ (usually with symbolic links to /usr/local/bin). I don’t remember where MacPorts put them, but it had its own structure as well. Apple’s command-line developer tools seem to go into /usr/bin, but macOS keeps track of where these are, in the case the user wants to remove them all. I have lots of tools developed with Go, which usually are placed (by convention) under ~/go/bin. Node’s own tools go into ~/node_modules; I forget where Python-based tools go, but usually they go ‘anywhere the user wants’.
And the list goes on and on…
Since there isn’t a common repository of ‘tools’, I don’t understand how Panic could develop an universal mechanism, built into Nova, that ‘discovers’ where such tools might be.
The best that could be accomplished, IMHO, would be an extension or plugin (I believe it would not require being built-in into Nova) that has the ability to search ‘popular’ repositories, such as those provided by MacPorts and Homebrew (and possibly Nix or even Snapcraft — I don’t know if those work under macOS), or maybe even those provided by Node via npm, Python, Perl (CPAN), LuaRocks, Go… — and possibly install whatever tools are required by an extension, on demand.
In turn, plugin/extension/theme developers would require to use an API to automatically register with the above-mentioned extension, ask it if some tool is found on one of the ‘registered’ repositories, and, if the user agrees, install it (if not already installed).
Theoretically, this could be provided by an external extension; all you need is a willing volunteer to write it 
And then you need to encourage other extension developers to use the exposed API — which will require some patience and persistence.
Is that what you’re proposing? If so, it seems that it’s something that could easily be done without hacking at Nova’s code.
But I might not be fully understanding what you actually have in mind, because, as far as I can see it, this is something costly to maintain — you would probably need a meta-database of all possible repositories (which are, in turn, written using all possible combinations of programming languages and have all sorts of backends), which needs to be regularly updated to be in sync with each and every one of the repositories. Just handling the dozen or so more popular ones would be enough of a nightmare!
Alternatively, of course, this extension could not have its own database, but rather query each repository independently — each of which of course requires handling such queries in completely different and unrelated ways — and sort of provide a ‘universal’ view to be presented inside Nova: there would be something like a ‘search tool’ where one would be able to make a keyword-based query, and the extension would show, among all repositories it knows about, where a matching tool might be found, and suggest to install it.
Now here is my point: assuming, indeed, that this is what you have in mind, I wonder what the cost/benefit would be for doing something so complex. After all, if you take a look at the number of people who have written some sort of extension/theme/plugin/etc. for Nova in the past two years, that number is relatively small. You can also note how many regular participants there are inside this Developer Forum. While it’s conceivable that such a number might grow in the near future — especially as new Nova users figure out that ‘there is no tool that provides X so perhaps I should just write it and release to the community’. But in any case I wouldn’t bet that we’re talking about millions of users, which is what all these independently maintained repositories have. Some might even have hundreds of millions — taking into account that CPAN, Pypi, LuaRocks, Go, Rust, Gems etc. etc. etc. are used by developers in all platforms, not just macOS, and they all share the same package repositories. As such, the return on investment on making more sophisticated repositories, or meta-repositories on top of existing ones (such as Canonical’s apt that works on top of the established dpkg manager for Debian; over which, in turn, GUIs have been written to handle package management visually…), is worth the effort, since any kind of ‘improvement’ will directly benefit millions or hundreds of millions of users.
But for Nova, how many people would directly benefit from such a meta-database for all repositories, integrated into Nova?
Also consider that each extension, by itself, might not require a lot of external tools, and those that are used will come from a very restricted and limited pool of such tools. In other words, if someone is doing a Perl extension for Nova, they will benefit from a direct connection to CPAN (for example) to retrieve packages on demand; similarly, the C# extension could benefit from a direct package retrieval facility from NuGet or other popular .NET repositories. However, it’s quite unlikely that the Perl extension will require any access to the NuGet repository; it’s not reasonable to assume, therefore, that whoever developed the Perl extension will benefit from whatever useful tools might exist on NuGet, and vice-versa. It is conceivable that some tools might, indeed, be useful for both — such as, say, Prettier. But on the flip side of the coin, it rather makes more sense to do an extension specifically for Prettier, which handles Prettier’s own extensions and themes and whatnots, instead of getting all programming language extensions use their own tweaked version of Prettier, coming from a centralised meta-repository integrated into Nova.
So, what I’m attempting to say is that it makes a bit more sense (in my own perspective, mind you!) to encapsulate whatever external tools might be required from within each extension/theme that will actually need such tools. And it will be up to the extension’s provider to make sure that such tools will be available, optionally asking the Nova user to put the path to a locally-installed tool on the Preferences window/tab.
In fact, one might even argue that such an encapsulation model — where external tools are only ‘known’ by the extensions that actually use them — is a good way to make sure that an old extension, which hasn’t been updated in a while, can nevertheless benefit from a newer version of its external tools, if the end-user has kept them up to date; if for some reason that newer version breaks compatibility with the extension, well, then the extension developer will most likely have provided its own, slightly outdated version of the required tool, but which was guaranteed to work at the time the extension was last updated.
This scenario obviously also works the other way round: I have dreaded to tinker around one of my language extensions that works with an external LSP. Nova’s support and integration with LSP has improved so dramatically that even without doing anything to the extension itself, both the improvements on Nova as well as on the externally-called LSP made ‘everything work as it should’ — without even requiring me to write a single line of code I totally admit that this is a lazy excuse, of course, but it nevertheless corresponds to the truth…
Contrast that with a central meta-repository which would handle all external tools on behalf of all the extensions. That way, I could never be 100% sure if the tests I made, at some point in time, with one specific version of a tool that was found on the meta-repository at the time of last updating the extension, will continue to work if the meta-repository, suddenly and unexpectedly, reinstalls a new version of the external tool before I have any chance to evaluate it. Since such changes are made at the macOS level — even if ‘moderated’ via Nova — it might not possible to reverse such a change (or even to be aware that any change occurred!). Or, alternatively, one might have a complex mechanism where the meta-repository’s API inside Nova also exposes methods to query for version numbers, check if the tool’s version is ‘compatible’ with what the extension expects, and optionally prevents the system to update such a tool if there is the risk of a breaking change. This is certainly possible to achieve, and, in some scenarios, it might even be a good approach; but it just makes the meta-repository, and the Nova extension that hypothetically would need to manage it, even more complex.
Consider also the case of having multiple repositories with not only the same external tool, but, more worrying, with long lists of dependencies that are mutually conflicting. Homebrew, for instance, takes some care not to overwrite any so-called ‘system’ tools, i.e. those that are already installed and being managed by macOS itself (via the Command-Line Developer Tool). But AFAIK this mechanism is not in place for other repositories. For instance, in some cases, I can use Homebrew to install a specific Perl package directly from Homebrew’s repository, because someone was kind enough to properly add such functionality, collaboratively sharing the management with CPAN itself. But this is by no means an universal requirement: in many cases, package managers, running as fully independent ‘magic black boxes’, are not aware of what other package managers in the same system are doing. Again, this might not be an issue with CPAN and NuGet installed on the same device — because most likely these repositories do not host the same packages) — but it will certainly be an issue with running Homebrew and MacPorts at the same time, having access to the same files on disk without being aware of the other’s existence.
I have no doubt that one advantage of having a meta-repository would be to make it so much easier to figure out conflicting installations from different package managers. But, again, that comes at the tremendous costs of maintaining the meta-repository in sync with every individual repository…
Then again, I might have completely misunderstood your feature request…