How to implement tools which have plugins that modify in place? (mdformat, mdformat-gfm, mdformat-myst etc)

[LumenLuminis]

Specifically about mdformat there were already issues #7674 and #3888 plus pull 3900 (and a comment on the original mdformat pull 2132)

Now the way mdformat plugins work, is that installing any of them changes the behaviour of the mdformat cli tool, instead of providing a specific binary or similar. That means you cannot install mdformat-gfm and use it to format according to commonmark specifications, or vice versa. You always need the entire installation that provides mdformat to match your intended style.

1. Personally, i only need mdformat-myst, which means i could add a registry entry of pypi: mdformat-myst (which pulls both mdformat and mdformat-myst if it works like pip), but that would still end up as a mdformat executable (though the mason venv should be different from my understanding). This would create a conflict if i install both mdformat and mdformat-myst as a mason package, since both exes have the same name and there is no tooling to deal with such conflicts as far as i know.
   This is a relatively small problem, and could theoretically be solved with a warning etc.

2. However, other people may have setups that include multiple plugins (mdformat-tables etc that work ontop of mdformat instead of different styles which modify the internal parsing directly), which would require having customisable installs, where you can interactively customise the tooling.

3. Additionally, one user might have multiple projects with differing requirements, and might want to install gfm parallel to commonmark etc to use on a per project basis.

I think to solve these requirements mason would need to implement some system to install the same tool multiple times (with different plugins etc), and dynamically link the executable of the chosen install and/or create symlinks with aliases to differentiate the installs.
But, this is a pretty big task and maybe not really in scope for a tool like mason.
If it is out of scope, i would like to know whether a PR for specific packages would be acceptable, like mdformat-myst, mdformat-gfm+mdformat-tables etc, because this would quickly balloon to many largely identical tools in the registry.

Alternatively, if the demand is small enough, having a hint in the package description towards the venv location and how to install tools into it might be nice. (This doesn't solve 3, but might be sufficient for 1&2)

[LumenLuminis]

The logic behind choosing where to use which tool etc might also be delegated to the formatting plugin, but then mason would still have to provide either differing links/executables or at least different installations so that the formatter can specify the absolute path instead

[Conarius]

I think this would be fitting for the mason repo instead of the registry here. But yeah, implementing that and then the registry structure here would be a big undertaking, so don't expect things to happen quickly.