Толстый Лорри

1. Да, задача может исполниться где угодно. Более того, вы не поверите, но некоторые таски вообще могут нигде не исполняться, т.к. исполнять нечего (см. п. 5). Таск - это прежде всего абстракция значения, которое будет получено в будущем, и для получения которого возможно нужно что-то посчитать или просто подождать. См. futures and promises.
2. Ну не обязательно в новом потоке, может быть выполнится и в существующем потоке если в пуле потоков есть свободный.
3. Асинхронные операции ввода-вывода называются так потому, что выполняются через асинхронное API операционной системы. Нет никакого смысла использовать асинхронную операцию, но делать это в отдельном потоке созданном специально для этой операции. Потоки нужны прежде всего для того, чтобы эффективно нагружать исполнителей, т.е. процессоры (в том числе разные их ядра).
4. Можно в новом, можно в потоке из пула. Так или иначе, если операция предполагает именно расчёты, а не ожидание ввода/вывода, то безусловно это тот случай, когда имеет смысл переложить нагрузку на другой поток.
5. Если представлять таск как одну из сторон "трубы", по которой прилетит результат асинхронной операции, то Task - это принимающая сторона, а TaskCompletiotionSource - передающая (производящая результат) сторона. Когда вы создаёте таск из кода который нужно выполнить, этот код становится передающей стороной. Но Task абстрагирует любую асинхронную операцию, не только ту где нужно долго что-то считать. Возможно вам нужно дождаться одного байтика из сети, и операция будет считаться завершенной. Во всех тех случаях, когда вы хотите самостоятельно "произвести" результат для какого-то таска (а сам таск отдать "наружу" другому коду, например вернуть из функции), вы можете использовать TaskCompletionSource.
(Кстати, в C++ принимающая сторона называется future, а передающая (производящая) - promise. В JS принимающая сторона называется Promise, а передатчиком является функтор).

Я делаю тоже самое, и тоже 2 года.
Но вот мне все также интересно, по вечерам читаю книги, на выходных смотрю видео.

Развиваться можно бесконечно.
Попробуйте почитать про алгоритмы и структуры данных, начнете смотреть на привычные вещи другим взглядом.

1) Род Стивенс - "Алгоритмы. Теория и практическое применение".
2) Джон Маккормик - "Девять алгоритмов, которые изменили будущее".

Выучите SOLID (Боб "Принципы, паттерны и методики гибкой разработки"), GOF (банда 4х, хватит https://metanit.com/sharp/patterns/), GRASP (Крэг Ларман - "Введение в объектно-ориентированный анализ, проектирование и интеративную разработку") наизусть, прочитайте книги авторов.

Работа работой, делайте свое дело.
А в свободное время учите и читайте то что вечно, или почти вечно - алгоритмы, паттерны и т.п., то что можно применить где угодно и на чем угодно. Не забивайте голову неиспользуемыми фрейворками (приходят и уходят) и другими языками программирования на которые не собираетесь переходить.

public class Repository<T> where T : IDbUpdatable<T>
{
}

public interface IDbUpdatable<T> where T : IDbUpdatable<T>
{
    Repository<T> GetRepository();
    int Update();
    int Delete();
}

Во-первых, хардкодить пути - это в целом плохая практика, а в Django особенно. Во-вторых, используя функции из модуля os.path можно писать код работающий с путями кроссплатформенно.

В квадратных скобках укажите размер

class ID3D11Buffer{};//объявим заглушку для примера

using PID3D11Buffer = ID3D11Buffer*;
using PPID3D11Buffer = PID3D11Buffer*;

int main()
{
    PPID3D11Buffer* g_pVertexBuffer = new PPID3D11Buffer[42];
}

Но вообще с таким подходом вы быстро запутаетесь. Используйте std::vector для массивов изменяемых размеров и std::array для неизменных.
Если же нужно обязательно объявление new sometype[count], то используйте вместо него en.cppreference.com/w/cpp/memory/unique_ptr/make_unique

Я не поклонник А. Лебедева, но иногда он говорит правильные вещи. Например, по поводу "Вышлете мне тестовое задание?" Он говорит - "а придумайте его сами!" Так и вообще с задачами. Нужно увидеть задачу. Точнее увидеть, как с помощью программирования вы можете перевести проблему из некоторого нерешённого состояния в решённое. В жизни задача никогда не скажет вам, что "вот она я, задача" и добровольно отдаст своё решение.
Когда я занимался легкой атлетикой, то думал, что есть два состояния, одно, когда я тренируюсь, а второе, когда я выступаю. Тренер мне объяснил, что состояние только одно - тренировка. Только на соревнованиях выкладываешься больше. Это вообще изменило моё отношение к поиску задач.
Если вы считаете, что способны решить задачу, то разве вы не способны её придумать? Каждая задача - это проверка своих возможностей, вызов. Если вы не работаете над решением задачи в таком ключе, значит вы неправильно и занимаетесь и работаете, т.к. нет развития.

https://msdn.microsoft.com/ru-ru/library/hb7xxkfx(...

en.cppreference.com/w/cpp/language/type_alias

в дополнении к первому ответу - включение двухфакторной авторизации во Вконтакте
https://vk.com/page-59800369_47885415