Your point about plugins is valid, but I believe a good middleground is having the plugins in core, but disabling them by default. Having an interface to enable

Your point about plugins is valid, but I believe a good middleground is having the plugins in core, but disabling them by default. Having an interface to enable particular plugins or plugin groups would be useful in this scenario too. I thought about contributing to asdf, but unfortunately many of my pain points are deeply integrated within the design and architecture of the code itself. For example, since there is a lot of code duplication within plugins, it would be good to create a "plugin API" (I think that has recently been proposed). But that would be very time consuming to implement not just because of the already-existing code, but also because essentially every plugin is its own separate repository, usually maintained by different people. So I'd think it's not too hard to imagine how difficult making broad improvements or changes will be. There's also the fact that writing (decently) fast and cross-platform Bash codes necessitates an essentially orthogonal coding style, which would be at odds with asdf's coding style. Even though the `REPLY` and `$()` is probably 80% of it, I would also like to take advantage of my `bash-core` and `bash-term` Bash libraries, which really wouldn't be possible in asdf (implementation-wise, that would necessitate the use of my Bash package manager)