nv-elispB

[The Elpaca installer] has a version-number variable that it sets. […] The solution is to replace [the installer with] the new code in elpaca’s docs

This is correct. For anyone troubleshooting Elpaca, there is a Wiki which covers this warning.

When you initialized your new Emacs instance, it installed elpaca from MELPA

This is incorrect. The installer directly clones Elpaca. Elpaca is not hosted on any ELPA. Doing so would require an installer package to be installed by another package manager. I don’t offer support for users running multiple package managers because it creates confusion about which package manager is responsible for which package, load-path entry, etc. MELPA rejected a similar proposal for straight.el as well:

https://github.com/melpa/melpa/issues/4939

cc: /u/liesdestroyer

Po Lu a week ago: less cl-lib please. Po Lu a couple days ago: What do you mean touchscreen.el shouldn’t be loaded by default?

lol Not that I think it’s a big deal (sorry for using you as an example, Po. I respect the work you’re doing, but I’m calling it as I see it). It does highlight how unproductive this type of bikeshedding is, though. That email chain is beyond novel length now and it’s still going. Almost makes me hope the “reply-to” button on the site stays broken.

In terms of what?

Properly package that code (sounds like you’re most of the way there) and let your package manager handle it.

Read the built in documentation.