If I understood correctly: you may also be interested in https://github.com/brettcannon/python-launcher (by one of the core Python devs). Although that specifically targets Linux. On Windows, the provided launcher is already aware of venvs (https://peps.python.org/pep-0486/) - although it only uses the currently activated venv, to my understanding.
Personally I'm not sure I like the idea of searching based on a folder name, as opposed to having some explicit registry of venvs. But this does seem to be more functionality than the existing options offer.
Out of curiousity, how do you typically make and organize your venvs?
Well when I'm doing data science at work, I typically work with conda environments, which then just work with runvenv because it finds them all. For my other "python -m venv" multi-use environments, I just stick them in ~/.venv, OR I drop a symlink in ~/.venv to them, so they're searchable, which makes ~/.venv into exactly an explicit registry by symlinks.
If it's a one-off environment for one program, I'll usually just make a venv and put it right next to the script. But the problem is I don't want the clutter of an environment in places that are in my executable path. So if I have something like a repo directory that has a python program and an environment, or ~/python with a python program and an environment next to it, then I just drop a symlink in ~/bin/ to the executable script, and now runvenv will follow that symlink, find the venv next to the script, and run it. So it kind of separates it. I can make my environments however I want or wherever I want with conda or venv, and the scripts using them are still directly executable. Either by adjacency to the script, or a symlink in ~/.venv to them (if I didn't make them directly in there). It doesn't functionally matter if they're accessed via a symlink, because the runpip tool takes care of handling that properly.