Кортежи против пользовательской структуры для асинхронной версии метода с параметром ref/out

Рассмотрим API C# с методом, который имеет параметр out или ref, например:

Person FindPerson(string name, out int searchTime);

Не будем обращать внимание на то, что параметры out и ref обычно являются дизайнерским запахом, допустим, это устаревший API и мы не можем изменить сигнатуру его существующих методов. Но нам нужно расширить API для поддержки асинхронного выполнения (Windows Phone, приложения WinRT). Вот реализация, которая не компилируется:

Task<Person> FindPersonAsync(string name, out int searchTime)
{
    return Task.Factory.StartNew(() => this.FindPersonAsync(name, out searchTime));
}

Эта реализация не будет компилироваться из-за параметра out. Поэтому нам нужно изменить подпись API. Один из способов — изменить результат с «задача человека» на «задача кортежа человека и целого числа», т. е. реализация делегата будет возвращать кортеж человека и целого числа. Второй вариант — определить пользовательскую структуру.

Преимущество кортежей. Использование кортежей дает очень формальный подход, который можно использовать для простого определения асинхронной версии для любого API. Предсказуемая реализация (новые имена не определены). Использование пользовательских структур требует изобретения новых типов и членов для каждого такого случая.

Преимущество пользовательской структуры: клиентский код, использующий кортежи, должен будет ссылаться на элементы Tuple, используя имена Item1 и Item2. Это неясно.

Я не нашел никаких рекомендаций и пока решил использовать кортежи. Но мне интересно, есть ли рекомендуемая практика для работы с такими методами при расширении API с поддержкой asyns.