In the "py.ini" file it is possible to specifiy customized commands (see https://www.python.org/dev/peps/pep-0397/#customized-commands).

Unfortunately it is not possible to specify custom commands beginning with  one of the buildin names (i.e. "python" or "/usr/bin/python"). 

This means that if I want to provide a virtual command like "python-xyz" I get an error message "Invalid version specification: '-xyz'" instead of running the executable assigned to python-xyz.

I would provide a Pullrequest if you accept this change in behaviour.

I am still waiting for a OK (or denial) of my proposed Modification.

I want to avoid that I start coding and when I am finished the PSF denies my PullRequest.

Is anybody out there who can decide this or at least lead a discussion?

Personally I don't see the value (in general, I don't see much use for the whole custom command idea - making the launcher into a generalised shebang processor was never really a core feature). But I'm not going to say no if others find it useful. Call me -0 on the proposal.

Of course I do not know the initial ideas/philosophy of the launcher.

But the current implementation supports these custom commands (for whatever reason). Thus I'd say they should work "properly". My view of "properly" is that the implementation matches the documentation which is currently definitely not the case.

Of course one could add an extra passus to the docs like: "custom command names must not start with 'python'". But why include a special case (and make it less intuitive) without need?

By the way: We have a use case for this custom commands and I could image others had, too. Or how came that they were included?

Not sure if Mark and Martin are part of an expert group, but neither are active in this area these days.

For the original question, I have no idea why the command can't use a builtin name, so hard to say whether we'd change it. A summary of why it's broken and what the fix would be is needed before we can say whether the change would be accepted or not.

Whether it should be this way or not, here's how it currently works. 

The builtin virtual paths all end with "python":

    static SHEBANG builtin_virtual_paths [] = {
        { L"/usr/bin/env python", TRUE },
        { L"/usr/bin/python", FALSE },
        { L"/usr/local/bin/python", FALSE },
        { L"python", FALSE },
        { NULL, FALSE },
    };

parse_shebang() loops over this list, simply matching up to the length of each virtual path. Thus "/usr/bin/env python-xyz" is matched as a virtual path. 

Supporting user configured "python*" commands would require more sophisticated matching. A virtual command has to consume a suffix that looks like a version string in the form "[x[.y]][-32|-64]", as determined by validate_version(). But otherwise configured "python*" commands don't have to be matched as virtual commands.