>> А зачем продолжать её исполнение?
> Здесь больше интересен вопрос: как по-мягче завершить её выполнение? Меня не устраивает
> заверешние через std::abort(), поэтому DMITIGR_ASSERT() генерирует std::logic_error,
> что предоставляет возможность самому приложению решать как именно закругляться (или не
> закругляться).

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

>> Если бы имя макроса содержало в себе что-то вроде COMMON или LIB, было бы сразу очевидно, что искать его следует в другой библиотеке.
> Так и было. Раньше он назывался DMITIGR_INTERNAL_ASSERT(). Но я не вижу в
> этом больше смысла.
>> Имеете ввиду, где-то отдельно уточнить? Если есть вариант с NOTHROW, почему нет с THROW?
> Вариант с "THROW" - это и есть DMITIGR_ASSERT().

При этом называется он не DMITIGR_ASSERT_THROW. В последнем варианте наименования все аргументы вида "семантика ассерта отличается" теряют смысл. :)

>> Тут пишут, что не просто бага, а тех, что могут быть исключены до выполнения программы.
> Это и есть баг. И всякий баг - это логическая ошибка. Можно
> ввести класс Bug, унаследованный от std::logic_error, но в этом смысл околонулевой
> - о классе std::logic_error знают все, кто пишет на C++.

__builtin_trap() - ошибка физическая (на x86 транслируется в UD2). SIGILL логическая. Тоже генерируют исключение, которое можно попробовать поймать, но перепутать его с подмножеством ошибок std::logic_error -- надо постараться.