On one hand, a tuple is versatile, but on the other, can be less clear.

As a best practice, should tuple not be used for the return type of a public method? Similarly, should it not be used for the type of any parameter of a public method?

In other words, should it only be used in declarations of protected, internal, and private methods?

+1  A: 

Ths issue is not public v private, the issue is simply 'what is good API design'. I think that you would rarely use Tuple in a C# API, and in the rare cases you do use it, most commonly it would be for a return type (when you want to return multiple things). But one should not be too prescriptive with overly general rules ("A foolish consistency..."); do the right thing for each individual situation. There may be cases for using it in parameters (especially e.g. in some interop with other languages).

Thanks for your answer, Brian. To me, the distinction between "public v private", vs "what is good API design" is a distinction without a difference, because isn't what you declare public part of your API (even if for your own consumption)? Anyways, the end your question, you get at the heart of the matter... you think it is "ok" to use publicly in situations that could warrant it, as utility can in the end, win out on self-documenting code. Not an opinion I am necessarily opposed to, however..
Jon Schoning
+1  A: 

I would tend to use the same guidance that I do for "raw" collection types like Dictionary<TKey, TValue> -- use something a bit more strongly typed. Inside your own internal methods it's fine, but use a more domain-specific type as a public input or output value.

+1 this is what I do.
Gabe Moothart