Glad that this topic is considered to be helpful!
I think @Dante-Broggi introduction of the term "clock domain" really helps talking about the issue:
Although I think that timeouts are more convenient than deadlines even when there is only a single domain (just look at the examples in [Pitch] Clock, Instant, Date, and Duration), deadlines are more versatile (and it is trivial to translate a duration to a deadline).
"My" naive solution to utilize deadlines created with a different clock would be transmitting the local time — with each message that is sent, during initial handshake, or following some clever rules.
One thing that brought me here is that keeping track of remote clocks frees you from the need to use a wall clock (with all its downsides). Instead, the sender could simply use its uptime clock (maybe adding some random number when you are concerned about revealing this information).
This does not help with latency, but even with two clocks in perfect sync, you'll still have to deal with that anyways: As long as you need an answer, this won't be there before deadline plus the time it takes to transfer the result (and maybe it is feasible to estimate roundtrip time).