If you want to replicate the lazy features then it will get verbose. Even using a dedicated plugin for lazy loading it's not as tight as lazy.nvim.

You may argue that you don't need lazy loading, which is fine, but they're not 1-to-1 compatible.

Nobody said they are 1-to-1 compatible. Also, ideally lazy loading should happen on the plugin side instead of putting it on every user to configure, since neovim natively basically has everything needed for plugins to do the lazy loading of heavy parts[1] and if something is missing it probably is better to add it the hooks for it upstream in neovim instead of the plugin manager so it also works for personal config/plugins.

[1]: https://github.com/neovim/neovim/issues/35562#issuecomment-3...

Yes, my point was that it's probably more verbose because it doesn't have the same feature set

I guess yeah, on me for missing that implication.

But as indicated by my comment in the specific case for lazy loading, the plugin manager is the wrong place to have it. Regarding its other features I am not sure most of them need to be part of the plugin manager either (at least from the "plugin spec" part) and are better suited as extensions to other parts of core neovim (e.g. options for plugins might need better `vim.{o,g}` support for nested objects, unsure). Maybe specifying nested dependencies might make sense to add to `vim.pack`.

All this to say: yea, now it is more verbose, but it doesn't have to be.