The only concern is when the Task was provided by a TaskCompletionSource, and whatever is supposed to utilize the TaskCompletionSource to set the result is eligible for garbage collection. Unfortunately there is nothing the consumer of the API can do in this situation unless they have access to and can hold a reference to whatever that is. Thus this is also gotcha for the provider of the API implementer in needing to be aware of this when returning such a Task.
Lacking better resources, I had to determine the above by a combination of tests (trial an error) and reading source code. However, in the absence of documentation that these are probably implementation details and could be subject to change in future releases of the .NET Framework.
Further Explanation
The Task class is sealed and it appears that TaskCompletionSource works by using a non-public API. Thus, excluding other MS APIs which could potentially use the non-public API and assuming libraries are not reflectively using Task's internals, the only implementations of concern are Task and TaskCompletionSource.
Task (not from TaskCompletionSource)
Besides those created by TaskCompletionSource, Task are created using members on Task or TaskFactory. Any started Task created by either of these methods is bound to a TaskScheduler. Since according to the Task-Based Asynchronous Pattern guidelines (excerpt) any returned task should be started, non-started is not a case a consumer needs to worry about.
According to the documentation for TaskScheduler.QueueTask on MSDN (emphasis mine):
A typical implementation would store the task in an internal data structure, which would be serviced by threads that would execute those tasks at some time in the future.
Thus, so long as the utilized TaskScheduler implementation adheres to that, the scheduler causes a reference to be maintained to the Task. This should keep the Task alive so long as the data structure used by the scheduler is alive.
The two TaskScheduler implementations built into the framework should be safe with respect to the storage of queued Tasks. One is a singleton and the other is backed by the SynchronizationContext so the queued tasks will be rooted so long as the context exists.
The base constructor for TaskScheduler registers all created TaskScheduler instances in a static list of active implementations, which should prevent any custom implementation from being garbage collected when it otherwise may have been eligible for collection. No issues should arise related to the scope of custom TaskSchedulers, unless the TaskScheduler does something uncouth in queuing tasks.
Overall, there is nothing really to worry about here.
TaskCompletionSource
TaskCompletionSources are not guaranteed to be rooted by anything.[1] Thus, there does exist potential for the TaskCompletionSource to be garbage collected before it sets the result.
Maintaining a reference to the object in which you called the Task-returning method could make a difference if the relevant objects for ensuring completion of the TaskCompletionSource are members of the object. While I cannot find any guideline for the TAP/TPL that such situations should be avoided, I hope they are clearly documented when they occur.
The Task returned by a TaskCompletionSource does not maintain a reference to the originating TaskCompletionSource, let alone whatever else is supposed to reference the TaskCompletionSource to set the result. So whether the consumer maintains a reference to the returned Task does not affect this issue.
In situations in which the objects needed for completion are scoped only to the task returning method, there is really nothing an API consumer can do to ensure correctness, and such situations should be considered a bug in the providing API.
