C#9 will reportedly support covariant return types, which in many ways mirrors Java covariant return types.

Covariant return types is a feature in which a subclass of a type can be specified in a method override in a derived type; consider Java:

public interface Appendable {
    Appendable append(char c);
}

public class StringBuilder implements Appendable {
    StringBuilder append(char c) {…}
}

Because StringBuilder ISA Appendable, StringBuilder can be used as the Appendable.append(char) return type instead of using Appendable.

Compare to the existing Xamarin.Android Java.Lang.StringBuilder.Append(char) binding, in which IAppendable must be returned, because C# lacks covariant return types.

This is a welcome development, and means that it would (presumably) be easier to deal with binding them; see also #216.

Unknown concern #1: what does this do with assembly versioning? If e.g. Mono.Android.dll v12 embraces covariant return types such that StringBuilder.Append() now returns StringBuilder instead of IAppendable, will that break existing code?

For most circumstances, @jonpryor can't see any issues with emitting covariant return types, mirroring what Java does. (Assuming that we can, based on the previously mentioned ABI compatibility question.)

Collection Interfaces

Once area where there will be problems is around collection interfaces. Consider Issue #647, in which generator currently wants to bind DownloadDrawablesAsync.doInBackground(), a method which returns a java.util.HashMap<String, Drawable>, as a System.Collections.Generic.IDictionary<string, Drawable>. This is "friendlier" to consume, as a C# consumed, but there is no way for IDictionary<TKey, TValue> to be a subclass of Java.Util.HashMap.

It is plausible that, since we already special-case collection interfaces, they will need to continue to be special-cased.