Вызов CancellationTokenSource.Cancel никогда не возвращается

CancellationTokenSource.Cancel не просто установить IsCancellationRequested флаг.

на CancallationToken класс Register метод, что позволяет регистрировать обратные вызовы,которые будут вызываться при отмене. И эти обратные вызовы вызываются CancellationTokenSource.Cancel.

давайте посмотрим на исходный код:

public void Cancel()
{
    Cancel(false);
}

public void Cancel(bool throwOnFirstException)
{
    ThrowIfDisposed();
    NotifyCancellation(throwOnFirstException);            
}

здесь NotifyCancellation способ:

private void NotifyCancellation(bool throwOnFirstException)
{
    // fast-path test to check if Notify has been called previously
    if (IsCancellationRequested)
        return;

    // If we're the first to signal cancellation, do the main extra work.
    if (Interlocked.CompareExchange(ref m_state, NOTIFYING, NOT_CANCELED) == NOT_CANCELED)
    {
        // Dispose of the timer, if any
        Timer timer = m_timer;
        if(timer != null) timer.Dispose();

        //record the threadID being used for running the callbacks.
        ThreadIDExecutingCallbacks = Thread.CurrentThread.ManagedThreadId;

        //If the kernel event is null at this point, it will be set during lazy construction.
        if (m_kernelEvent != null)
            m_kernelEvent.Set(); // update the MRE value.

        // - late enlisters to the Canceled event will have their callbacks called immediately in the Register() methods.
        // - Callbacks are not called inside a lock.
        // - After transition, no more delegates will be added to the 
        // - list of handlers, and hence it can be consumed and cleared at leisure by ExecuteCallbackHandlers.
        ExecuteCallbackHandlers(throwOnFirstException);
        Contract.Assert(IsCancellationCompleted, "Expected cancellation to have finished");
    }
}

хорошо, теперь подвох в том, что ExecuteCallbackHandlers может выполнять обратные вызовы либо в целевом контексте, либо в текущем контексте. Я позволю вам взглянуть на ExecuteCallbackHandlers метод исходный код как это немного слишком долго, чтобы включить здесь. Но самое интересное:

if (m_executingCallback.TargetSyncContext != null)
{

    m_executingCallback.TargetSyncContext.Send(CancellationCallbackCoreWork_OnSyncContext, args);
    // CancellationCallbackCoreWork_OnSyncContext may have altered ThreadIDExecutingCallbacks, so reset it. 
    ThreadIDExecutingCallbacks = Thread.CurrentThread.ManagedThreadId;
}
else
{
    CancellationCallbackCoreWork(args);
}

Я думаю, теперь вы начинаете понимать, где я собираюсь искать дальше... Task.Delay конечно. Давайте посмотрим на его исходный код:

// Register our cancellation token, if necessary.
if (cancellationToken.CanBeCanceled)
{
    promise.Registration = cancellationToken.InternalRegisterWithoutEC(state => ((DelayPromise)state).Complete(), promise);
}

Хммм... что это?!--42-->InternalRegisterWithoutEC метод?

internal CancellationTokenRegistration InternalRegisterWithoutEC(Action<object> callback, Object state)
{
    return Register(
        callback,
        state,
        false, // useSyncContext=false
        false  // useExecutionContext=false
     );
}

Аргх. useSyncContext=false - это объясняет поведение вы видите, как TargetSyncContext свойство используется в ExecuteCallbackHandlers будет false. Поскольку контекст синхронизации не используется, отмена выполняется на CancellationTokenSource.Cancelконтекст вызова.