Универсальный обработчик успехов перегрузок механизма обратного вызова как средство для управления потоком - кодирует запах?

Я являюсь довольно новым на проекте и натыкался на интересную парадигму дизайна для некоторых асинхронных вызовов, которые мы выполняем к базе данных (переменные и имя функции измененный):

private void OnLogin(object selectedInitialState,
                     AsyncEventCompletedCallback<EmptyAsyncEventArgs> userCallback,
                     object userState)

Использования в качестве примера:

OnLogin(
    null,
    args =>
    {
        if (args.IsSuccess)
            DetermineNextStep(); //When done, continue to this step
        else
            //NOTE: This probably means we couldn't connect to the DB
            // Handle this case
    },
    null);

OnLogin(
    newInitialState,
    args =>
    {
         ReLoginUser(); //Was logged in; re-logging in user with different initial state
    },
    null);

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

То, что беспокоит меня, - то, что функция обратного вызова в этих двух случаях отличается. Я привык видеть функциональное взятие обратный вызов, чтобы позволить пользователям функции обеспечивать пользовательские реализации в области вызванной функции.

В вышеупомянутом случае, тем не менее, функция обратного вызова изменяет поток управления. В зависимости от которого функция обратного вызова обеспечивается, последующие функции вызова после того, как возвраты асинхронного вызова будут отличаться. Действительно ли это - запах кода или просто изобретательное использование для обратных вызовов?