Александр Юдаков

• std::string — как правило, если не указано противное.

• QString, AnsiString/UnicodeString и прочие — в соответствующих фреймворках, обычно очень близко к интерфейсным функциям.

• char* — практически не используется в реальном коде. В основном для оптимизации, если есть собственное управление памятью. Довелось как-то в собственном разборщике XML (работает в 2,5 раза медленнее рекордсмена, pugixml. Зато даже это в разы быстрее Excel’я, пространства имён «из коробки», расход памяти мизерный и программирование простейшее.)
Зато по-чёрному используется его const-аналог.

• const char*. Это может быть одинокий const char* + нуль-терминированная строка, или указатель+длина, или указатель на начало + указатель за конец.
1. Если ожидается, что в функцию будем передавать строковый литерал.

void writeEnum(st::Stream& st, int value, const char* names[]) {}

enum class Letter { A, B, C, …, Z, NN };
const char* natoNames[static_cast<int>(Letter::NN)] = { "alpha", "bravo", "charlie", … };
writeEnum(someStream, static_cast<int>(Letter::E), natoName);

2. Если операцию со строкой можно произвести «на месте», не заводя новую память: (trim, как известно,— обрезка пробелов в начале и конце)
void trim(const char*& beg, const char*& end);

3. Если структура данных паразитирует на чужих строках, не заводя своей памяти. Особенно если конструкция строк неизвестна (например, при передаче данных из плагина в плагин).
struct ParasiteString { const char *beg, *end; };

4. В библиотеках, если они реально настолько компактные, что нет нужды обязательно подключать жирный STL.

• char[] — только как оптимизация, когда предельная длина строки известна и невелика.

wchar_t* myFtos(double value, wchar_t* buf, const FloatFormat& format) {}

wchar_t buf[100];
myFtos(100.500, buf, FloatFormat::NICE);

Если, как Вы говорите, проект написан чисто, задокументирован и адекватно выполняет свои задачи, то зачем его переписывать? Если дело только в виндовс, то дешевле и быстрее перевести под Core, будет Вам линукс.

насколько адекватно оставлять Backend на C# в 2018 году?

Вот именно сейчас это адекватно) Большинство нового интерпрайза начинают писать на C#. Нам, наоборот, приносили большой проект с Питона переписать.

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

Не знаю как у вас с английским, но есть такое старое видео https://www.youtube.com/watch?v=vXjVFPosQHw про архитектуру масштабируемых приложений. Там как раз рассказывается про общие принципы. Презентация из этого видео - https://www.slideshare.net/nzakas/scalable-javascr... , в принципе там есть примеры кода, думаю, будет полезна.

Что то вы путаете, требование, как было, так и осталось.

void ReadLog(Parser& input, mutex &m) {
  if (input.filename != "")
    input.ReadLog(m);
}

void ParceEvents(Parser& input, mutex &m) {
  if (input.filename != "")
    input.ParseEvent( m);	
}

Изменить без проверок можно или программно с ОбменДанными.Загрузка = Истина или обработками, которые умеют использовать тот же параметр, например Групповая обработка справочников и документов (есть галка) - есть в большинстве типовых или найти как внешнюю.
Что бы увидеть использование товара вам подойдёт Все функции - Стандартные - Поиск ссылок на объекты.

NtCreateFile находится в NtDLL.dll
Думаю, что можно использовать LoadLibrary/GetProcAddress для загрузки библиотеки и адреса функции.