Stanislav Aleksandrov's RFC patch addresses a limit of relative submodule URLs. A URL like "../../org/lib.git" breaks when the superproject is forked to a different depth, for example into a GitLab subgroup. An absolute URL does not break, but it forces one protocol on everyone.
The patch resolves a URL starting with "^/" against the superproject's remote, like "../", but from the root of the server, keeping protocol, user, host and port. "^/org/lib.git" maps to https://host/org/lib.git for an https remote and to git@host:org/lib.git for an ssh-style remote. Unlike "../", it fails for a superproject cloned from a local path or without a remote, and for "<transport>::<address>" remotes.
Jacob Keller noted that protocol.file.allow defaults to "user", so submodules generally cannot use file-based URLs interpreted as local paths. Only unusual setups could currently rely on a leading "^", and he judged the chance of breaking anyone low. He said he likes that "^/" has precedent in SVN, but that adding new special characters is always problematic.
Jacob asked whether .gitmodules could be extended to carry this information, and whether the same effect could come from URL rewriting. Stanislav said not as a rewrite rule: a rule maps one fixed prefix to another, while .gitmodules is the same for everyone and cannot send one person over https and another over ssh with their own host alias. What differs per clone is the superproject's remote URL, which "../" and "^/" resolve against.
Stanislav said a separate "same server as the superproject" key beside an absolute URL, which Git would then ignore the host of, would be confusing. He also said "^" is a valid directory name today, so "^/org/lib.git" currently means a repository in a "^" directory of the superproject. Jacob's last question about what "refuses" meant for the character was a response to that point. The design is still open.