Have you considered something like this? (patch against 3.1)

--- Python/sysmodule.c.orig
+++ Python/sysmodule.c
@@ -1643,6 +1643,7 @@ PySys_SetArgv(int argc, wchar_t **argv)
 #endif /* Unix */
 		}
 #endif /* All others */
+		if (n > 0 || argv0 == NULL || wcscmp(argv0, L"-c") == 0) {
 		a = PyUnicode_FromWideChar(argv0, n);
 		if (a == NULL)
 			Py_FatalError("no mem for sys.path insertion");
@@ -1650,6 +1651,7 @@ PySys_SetArgv(int argc, wchar_t **argv)
 			Py_FatalError("sys.path.insert(0) failed");
 		Py_DECREF(a);
+		}
 	}
 	Py_DECREF(av);
 }

I presume main problem here is that '' may end up as first item in
sys.path in certain cases.

That is desired in some cases, namely:
- python run in interactive mode
- python -c '...'

It does not happen and is not desired in other cases:
- ./foo.py
- python foo.py
- env python foo.py

Here foo.py can be just filename or filename with relative or absolute
path.  In all these cases python seems to set argv0 to something
realpath can resolve.

Problematic case is embedded use when bogus argv0 can cause '' to be
added to sys.path, but it's usually not desired / expected (is anyone
aware of the case when that is expected?).  It can be argued whether
apps should use garbage as argv0, but example in Demo/embed/demo.c do it
as well...

Patch above attempts to skip modification of sys.path when realpath
failed (n == 0).  There are two special cases, that are treated as
special on couple of other places in PySys_SetArgv already:
- argv0 == NULL (interactive python)
- argv0 == "-c" (python -c)

This should fix the problem for apps embedding python and providing
garbage argv0.  It would not make a difference for apps that provide
some valid path as argv0.  I'm not aware of non-embedded python use that
will end up with different sys.path after this patch.

Ideas?  Anyone is aware of the valid usecase that can break with this?

Advantage to Ex approach is that it does not require change on the
embedding apps side, and should really impact only those setting garbage
argv0.