and worker.DoWork() would not be possible, because DoWork has a return type. Ignoring the return is not 'first class' as Erik would call it
Today, worker.DoWork() is valid. You don't have to care that there's a return type. In a theoretical world, you can't make it always required that you capture the return value as that would be a breaking change. You could make it required only when there's
such "overloads", but that's probably not a good idea as it introduces some tricky versioning scenarios. And that's all ignoring the very valid points that Massif has made. You may not like 'var', but it exists. There's also the issue with base types causing
ambiguity. Technically, none of this prevents the introduction of overloading based on return type, as it's really no different from overloading based on out parameters, but it certainly seems like it would be much more confusing for developers and maintainers.
I don't think it's a good idea.