Issue 13475 provides some additional context for discussion of changes to the sys.path initialisation process. The status quo is that I'm currently wary of adding more complexity to an already fragile initialisation sequence for things that can be implemented by way of running a custom launch script that uses the runpy module to replicate the CPython script invocation options.

In the specific case of this patch, while the idea is one we've considered before (and may end up implementing some day), this specific implementation adds new path initilisation logic directly in Py_Main, well away from getpath.c (which, in collaboration with site.py, is intended to fully handle the path initialisation logic), and without being separated out into a distinct API that embedding applications can easily take advantage of. A lot of Python code will also run *before* the command line arguments are processed, so you'll end up with a case where code run early may pick up a version of a module from later in sys.path, giving the appearance that the sys.path additions are being ignored, even though they appear in sys.path after the program is fully initialised.

While the technical concerns mean it isn't likely this particular approach would be pursued further, as a practical matter, additional things that would be needed for a patch to the interpreter argument handling to be accepted include:
- a signed contributor licensing agreement
- documentation upates in the "using" guide
- a new test (or tests) in Lib/test/test_cmdline.py and Lib/test/test_cmdline_script.py