It was never the intention that the code calling public dispatch methods use the Result property set into the interception context after the dispatch method has returned. The dispatch method returns the result (or a task for the result) and this was what was intended to be used.
Currently the Result property may be set if:
1. A new interception context is not created as part of dispatch processing
2. The operation being executed is not async
3. Some result is actually set
Number 1 can be fail to hold if, for example, the a new interception context is created to set the async flag, handle and exception, etc.
Number 2 obviously fails to hold for all async calls
Number 3 fails to hold if the operation throws or is canceled
Because of all the above, but especially the async limitation, it is not possible to always make the result available in the interception context when the dispatch call returns. So the question becomes whether or not it is okay that it is sometimes set and sometimes not. If it is not okay, then we can add code that makes sure the result is _never_ set when the dispatch method returns.
Currently the Result property may be set if:
1. A new interception context is not created as part of dispatch processing
2. The operation being executed is not async
3. Some result is actually set
Number 1 can be fail to hold if, for example, the a new interception context is created to set the async flag, handle and exception, etc.
Number 2 obviously fails to hold for all async calls
Number 3 fails to hold if the operation throws or is canceled
Because of all the above, but especially the async limitation, it is not possible to always make the result available in the interception context when the dispatch call returns. So the question becomes whether or not it is okay that it is sometimes set and sometimes not. If it is not okay, then we can add code that makes sure the result is _never_ set when the dispatch method returns.