I suspect you'd need adoption before authors would want to maintain a Pluginfile.json, and before there's a decent selection in your repo there's not a selling point to gain adoption.
A tool that can help me find things like git-series would be cool, but I think you'd need to work downstream rather than having every git plugin know about your package manager. If you're gonna make repos to wrap upstream projects into your package format (which is what Linux distros do), then that could work.
It's called a plugin, but it's actually a manager for git aliases.
Integrity verification of distributed packages (ideally cryptographically) is a core and required feature of a package manager.
At an absolute bare minimum you need a Lockfile style mechanism to allow users to ensure two installs are the same.
I understand your sentiment, but it's wrong. You need to take into account your userbase, potential or otherwise.
There are those which will be overzealous and not concerned about security and will use your stuff anyways, then there are those people who find themselves compelled (against their will) to use it, secure or otherwise.
Because this software strongly facilitates the later group, releasing it in this fashion represents a security risk and is unethical, wrong, even.
Just because you can manufacture a bomb does not mean you should, not should you be distributing bomb making kits.
Also, perhaps your time would be better spent building this functionality into existing package managers, rather than this one? There are certainly enough package managers out there, I'm not convinced this is even a good idea.