GUN_ter

Похоже на ошибку оформления. Это должен быть вызов функции. В тексте выше даже написано про вызов.

Тут автор считает, что сначала выполнится new A(), потом new B(), потом конструктор unique_ptr. Если исключение бросит B(), то действительно будет утечка памяти. Объект A, полученный через new умрет еще до оборачивания в unique_ptr. Такой сырой указатель автоматически не удалится.

Такая последовательность невозможна c С++17:

In a function call, value computations and side effects of the initialization of every parameter are indeterminately sequenced with respect to value computations and side effects of any other parameter.

Evaluations of A and B are indeterminately sequenced : they may be performed in any order but may not overlap: either A will be complete before B, or B will be complete before A. The order may be the opposite the next time the same expression is evaluated.

Но до C++17, действительно, компилятор может перемешать вычисления аргументов как угодно.

Это не сборка мусора, а подсчёт ссылок в иерархиях объектов и ручное освобождение памяти иерархий.
В сборщиках мусора это реализовано автоматически, и сама сборка мусора с подсчётом ссылок происходит не в самые подходящие моменты - мусора либо слишком мало, либо слишком много.

Согласен с maagames.ru - можно задать просто другой родительский объект, и удалять его, вместе со всеми ответами/запросами, по требованию.

if you don't call QObject::setParent() on them.

Задай другой родительский объект и они удалятся вместе с родителем.

Сборка работает по иерархической модели - породивший объекты класс при своем удалении уничтожает потомков (посылая им сигнал).

Хотите улучшить - удаляйте сами, ничего страшного не случится.

Зачем Clang использует gcc? Для компиляции?

Сам компилятор не используется. Только линкер и стандартная библиотека.

Почему считается, что использовать Clang для (кросс-)компиляции, и в CMake лучше, если он использует тот же gcc?

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

GUI-клиенты удобны и ими стоит пользоваться. Но проблема в том, что не всё, что можно сделать в консоли, доступно в графических интерфейсах. Некоторые операции, особенно низкоуровневые, делаются исключительно через терминал и нет никаких причин выдумывать графический интерфейс для них.

Можно ли это сделать через TortoiseGit?

Нет, не получится. Извините, но TortoiseGit один из самых ущербных клиентов, которые я видел. Он не умеет практически ничего. Максимальный функционал реализован в SmartGit и ещё в средах разработки от JetBrains.