ValueTask<T> not a subset of Task<T> , it is a superset .
ValueTask<T> is a discriminated union of T and a Task<T> , which makes it without highlighting for ReadAsync<T> to synchronously return the value of T that it has (as opposed to using Task.FromResult<T> , which needs to be highlighted a Task<T> ). ValueTask<T> is expected, so the highest instance consumption will be indistinguishable from Task<T> .
ValueTask, being a structure, allows you to write async methods that do not allocate memory when they are run synchronously, without compromising API consistency. Imagine you have an interface with a task return method. Each class implementing this interface should return a Task, even if they are executed synchronously (I hope using Task.FromResult). Of course, two different methods can be used on the interface: synchronous and asynchronous, but this requires two different implementations to avoid "synchronization by asynchronous" and "asynchronous synchronization".
Thus, it allows you to write one method that is asynchronous or synchronous, rather than writing the same method for each of them. You can use it wherever you use Task<T> , but this often does not add anything.
Well, this adds one: it adds an implied promise to the caller that the method actually uses the extra functions that ValueTask<T> provides. I personally prefer to choose the options and return types that tell the caller as much as possible. Do not return an IList<T> if the listing cannot provide an invoice; do not return an IEnumerable<T> if possible. Your consumers do not need to look for any documentation to know which of your methods can reasonably be called synchronously and which are not.
I do not see future design changes as a convincing argument. On the contrary: if a method changes its semantics, it must break the assembly until all calls to it are updated accordingly. If this is considered undesirable (and believe me, I sympathize with the desire not to break the assembly), consider interface versioning.
This, in fact, is what is for strong typing.
If some of the programmers developing asynchronous methods in your store cannot make informed decisions, it may be helpful to appoint a senior mentor for each of the less experienced programmers and conduct a weekly code review. If they are mistaken, explain why this should be done differently. This is overhead for the older guys, but it will make juniors accelerate much faster than just throwing them into a deep corner and giving them some kind of arbitrary rule.
If the guy who wrote the method does not know whether it can be called synchronously, who is doing on Earth ?!
If you have many inexperienced programmers who write asynchronous methods, do the same people call them? Are they qualified to figure out for themselves which ones are safe to call asynchronous, or will they begin to apply a similar arbitrary rule to how they call these things?
The problem here is not your return types, but the fact that programmers are put in roles that they are not ready for. This was supposed to happen for some reason, so I am sure that this cannot be trivially fixed. Describing this, of course, is not a solution. But looking for a way to get into the problem past the compiler is also not a solution.