Let me start by saying I'm aware that the git+ssh:// example is not a great one, as it's superfluous and not needed in practice.
The spirit of my question is about nested URL schemes (which may be many deep), and how to go about expressing a specific application layer protocol which may run on top of one or many other transports alternatively to a native one.
For example if I'm making a "chargen" service, and I have a GUI desktop application set up to handle chargen://example.com:19/ that's pretty straightforward. But if I wanted to support a version of chargen that could run over the top of https, I need to express that. I also want to be able to click on a hyperlink and have an appropriate application handler take charge of that protocol. So to follow git's example, it might look like chargen+https://example.com/ or maybe chargen://https://example.com/
In the real world, I recently used a service that offers published calendars for subscription, and shares a link that looks something like webcal://host.example.com/calendar/xyz. Unfortunately, this doesn't carry enough information to indicate whether the resource is HTTP or HTTPS. (Of course it should be HTTPS, but my point is in seeking the ability to clarify layered protocols).
So to summarize my actual question, I'm looking for standards or well adopted practices that are able to clearly and unambiguously specify how to resolve a service that is being served over multiple layeres of protocols.
I just came across IANA's list of URI schemes, and it does appear that there is an established precedent for the a+b:... style. That is a sufficient answer for me.