This isn't Tor-like multi-hop (but is similar to other multi-hop VPN providers out there). A proper multi-hop would happen across two different vendors in control of two different networks, as it were.
The iCloud Relay paper outlined a pretty private and secure design [0] (and the intention to standardize it via IETF would probably make it simpler to self-host such a solution [1][2]). Among the VPNs, orchid.com's distributed VPN stands out as a cross-provider multi-hop solution whose privacy guarantees are closer to Tor's.
Eventually the hope is HTTP (www) itself bakes in desirable privacy properties, so regular users don't have to pay the cost of multi-hops [3].
Shameless plug, for my undergraduate senior thesis in 2014 I coauthored a paper related to this called “A TorPath to TorCoin” [0]. The main premise was proof-of-bandwidth cryptocurrency, but its resistance to Sybil attacks was partially dependent on assignment of publicly verifiable but privately addressable circuits. So the “TorPath” part was about circuit assignment, and in retrospect perhaps more interesting than the cryptocurrency aspect of it. The tl;dr is a Neff shuffle with a matrix of relays and assignment servers.
We never developed it further beyond the initial research (it was senior spring, not a lot getting done, I even forgot to buy Bitcoin). I remained (and remain) interested in decentralized VPN networks, and played around with implementing something around it, but ultimately I didn’t have the experience to build what I wanted.
Personally, I like what Orchid, Tailscale and ZeroTier are doing. I also like Fly.io and Cloudflare Workers and generally any product that iterates toward a Network Function Virtualization (NFV) platform. The root obstacle is incumbent compute-based clouds oversubscribing compute by gouging on bandwidth. This makes the cloud environment inhospitable for any cost-effective, transit-intensive business like a CDN/VPN, increasing the barrier to entry by requiring self-hosting a distributed network.
Since it's the same company with access to both the first and second server, it wouldn't be too hard to log network on both ends and sync it up.
With iCloud Private Relay, it'd be harder for a single actor to de-anonymize requests; you'd either need collusion between the companies or a government entity would need to ask both companies to log network traffic at once, and this would complicate the "exit node" server since it can't filter/only record traffic from the target customer's connection without company 1 setting up a single server dedicated to being the proxy for that customer.
The point of multihop, tor or otherwise, is for each node in the route to not know what the other knows. The first node sees packets coming from you, but not where they're going. The second see's where they're going but doesn't know where they're from (and vice versa). If the two nodes exchange this info (ex. if same person runs both nodes) then there's no point. Nothing is gained, you just incur the overhead of the extra hop.
Where is this defined? Because the word multi-hop only implies more than one hop. Anything else needs to be defined as a specific algorithm, like onion routing for example. That's why I think this is semantics.
For what its worth I have used the open source Tinc VPN [1] for mesh multihop routing for ages. It is nowhere near as fast as Wireguard but I could envision Tinc incorporating support for Wireguard if the author were so inclined. Like you mentioned Tinc does not mesh directly with other VPN's AFAIK. I've had to use route statements to join it with Strongswan and other VPN networks.
We never developed it further beyond the initial research (it was senior spring, not a lot getting done, I even forgot to buy Bitcoin). I remained (and remain) interested in decentralized VPN networks, and played around with implementing something around it, but ultimately I didn’t have the experience to build what I wanted.
Personally, I like what Orchid, Tailscale and ZeroTier are doing. I also like Fly.io and Cloudflare Workers and generally any product that iterates toward a Network Function Virtualization (NFV) platform. The root obstacle is incumbent compute-based clouds oversubscribing compute by gouging on bandwidth. This makes the cloud environment inhospitable for any cost-effective, transit-intensive business like a CDN/VPN, increasing the barrier to entry by requiring self-hosting a distributed network.
[0] https://dedis.cs.yale.edu/dissent/papers/hotpets14-torpath.p...