They’re free to do just that, especially if there isn’t an alternative API in base Julia. Work on base Julia, including juliac, never obstructed PackageCompiler’s development, and as explained, it’s quite the opposite because the bulk of PackageCompiler’s work always involved base Julia’s compiler and package implementation. The fact that PackageCompiler and other packages like Revise, JET, and Cthulhu are not in the standard library doesn’t contradict their heavy dependence on base Julia, and base Julia absorbing every such package when they hit some popularity threshold would not automatically improve reliability or priority, but it would definitely bloat installations.
If anything, juliac’s existence made more people care about the things PackageCompiler does. Loading the entire Julia runtime with a custom sysimage isn’t feasible in some situations, and the latency and overhead is unnecessary and undesirable in many more. This really limited the usage of PackageCompiler, even users would mix packages as much as possible on the typical Julia side for one shared library instead of reusing multiple shared libraries, which goes beyond the normal headaches of language interop. I’d hazard a guess that the relocation problem is part of figuring that out.