In MonoTouch.UIKit.UIPrinterPickerController, the method:
public virtual System.Threading.Tasks.Task<MonoTouch.UIKit.UIPrinterPickerCompletionResult>; PresentAsync (bool animated, out bool result);
contains an `out bool` parameter that captures (I think) whether or not the user selected a printer. The UIPrinterPickerCompletionResult that is passed to the Task<T> contains a field that does exactly this. There are other versions of PresentAsync that make more sense to asyncify.
This is not an isolated issue, as there are other places (in UIKit, alone) where this occurs.
Maybe only asyncify the PresentAsync overload that does not contain an `out bool` parameter that is captured in the return value. (Though that sounded like snark, I meant only to convey that, while I can't see a reason for these bindings, there may be one of which I am not aware.)
There might be other cases but both `out` and `ref` are good signs of API that are not really usable with async.
What we need to do, in no particular order
1. btouch should emit a warning if `[Async]` is used on such API; it cannot be an error since it would break binary compatibility for anyone who made that mistake. It's possible to use `-warnaserror` to avoid future mistakes;
2. Our introspection tests should spot those conditions and report errors on the bots;
3. Obsolete our existing API that expose `out` or `ref` parameters and exclude them from XAMCORE_4_0;
@Alex please start with #1. I'll try to handle #2 and #3 independently.
Hello Mike I want to explain a bit more about the why this is not a bug in the current exposed API
This is the selector that 'UIPrinterPickerController.PresentAsync (bool animated, out bool result)' uses under the hood 
The 'out bool result' is the actual boolean "Return Value" that the native selector returns, the documentations says that this value is
> YES if the picker was displayed or NO if the picker was already visible.
There is no other way to fetch this return value from our current [Async] implementation now answering your actual concern
> contains an `out bool` parameter that captures (I think) whether or not the user
> selected a printer. The UIPrinterPickerCompletionResult that is passed to the Task<T>
> contains a field that does exactly this.
This is not completely true, as I mentioned above the 'out bool result' returns the selector result, true or false depending if picker was already visible according to docs , the actual bool you get from UIPrinterPickerCompletionResult is the one that captures if the user selected a printer or if the user canceled the selection process.
So to recap a little if you use [Async] on a member that returns something we will generate a *Async method variant that takes an 'out var foo' so there is a way to fetch the actual return value of a selector and we'll also generate another variant of the same *Async method without the 'out var foo' so you can ignore the return value if you are not interested in it.
Now after all the above explanation I must also thank you Mike for this bug report, we will now generate an error if someone tries to use [Async] with a method signature that takes an out or ref parameter.
Oh I should also mention something to @Sebastien: fortunately we do not have these mistakes on the API so there is no need for Obsolete'ing API or introspection tests, we generated uncompilable code so there is no way we are breaking someone :D