Asynchronous replies in UML sequence diagrams (async/await pattern)

Many modern languages promote asynchronous calls, with a way to wait for the result when it's really needed. Example: async/await in C# and Swift or promise/future in C++. Take the following hypothetical implementation :

class X { 
  private Y y; 
  public async void doSomething() {
    var someTask = y.doSomeAsyncOp();// Asynchronous call 
    doSomethingImmediately();        // Potentially in parallel with async behavior
    var result = await someTask;     // Getting or waiting for result of async call
  }
  ...
}

This implements the intent of a reply for the async call in the design:

Unfortunately, according to the UML 2.5.1, reply messages seem to be meant only for synchronous calls and asynchronous calls are not supposed to have replies. See section 17.4.3:

If the messageSort is reply, then the Message represents the return from a synchronous call to the Operation. The arguments of the Message correspond to the out, inout and return ownedParameters of the Operation (...).

Section 13 of the specifications, which defines synchronous and asynchronous behavior, is consistent with this understanding. So, how to model the design with legit UML?

• asynchronous message in the opposite direction: would work very well if there would be some callback operation. But in absence of callback, what would be the signature of the message?

• model the await with a second, synchronous invocation to the end of y's execution specification. Pro: it materialises the synchronisation. But what would be the message signature?

• intermediate Task lifeline would not be a relevant solution: the very detailed implementation level UML diagram would then be harder to understand than the code. And it doesn't convey well the design intent.

Even though the async/await pattern is used for asynchroneous communication, both the call to the operation and the await have return values and the sender has to wait for them. Therefore, I would suggest to use synchroneous calls.

The connection between the two messages is the assignment target someTask of the first operation used as the argument of the await.