I noticed that splittist reported on #abcl that abcl-0.23.0 has fails to start if it is in a directory that contains #\Space characters.
The problem is related to my "fix" for loading Pathnames that contain #+ characters which reveals that we are too undecided with our encoding of a JAR Pathname.
The problem arises by not rigorously treating Pathnames with "jar:" and "file:" prefixes as having URLEncoded DIRECTORY, NAME, and TYPE components, which seems to be how the java.net.URL classes treat them. Although this seems innocent, when ABCL loads its FASLs it always using this code so this deeply effects the system operation, although normally no one actually constructs such URLs.
My proposed fix would be to treat all inputs to Pathname which construct with "jar:" and "file:" schema as being URLEncoded. Likewise, we would fix the namestring routines to provide such encoding on the "way out" to string representations.
There would therefore be a difference between (pathname-directory "file:/containing%20a%20space/") ==> (:ABSOLUTE "containing a space")
and (pathname-directory #p"/containing%20a%20space/") ==> (:ABSOLUTE "containing%20a%20space")
There would be a bit of a surprise that
(pathname-directory "file:/cl+ssl!/foo.lisp") ==> (:absolute "cl ssl")
It will take some time to chase down all the code paths here, so please comment if this solution is still ambiguous in some way that I haven't anticipated, or if someone has different proposal.