res2001

Если потоки точно не пересекаются нигде, мьютекс не нужен, а ошибка где-то в другом месте.

Т.к. и базовый класс и класс-наследник являются шаблонными, то компилятор C++ считает, что члены класса mnoj являются так называемыми "зависимыми идентификаторами" (dependent names). Такие идентификаторы по-умолчанию не включаются в процесс разрешения имён и их нужно "затаскивать" в него явно.

Вариант 1 (советую его): обращаться к полям базового класса через this: this->index - это вообще хорошая практика - сразу видно, где используется локальная переменная, а где идёт работа с состоянием объекта.
Вариант 2: использовать using mnoj<T>::index; и using mnoj<T>::mas внутри описания класса mnoj1.

int a(10); // работает
MyStruct b(); // не работает

смотри, я пофиксил твой кейс:

int a(); // не работает
MyStruct b(); // не работает

-- теперь одинаково не работает. Ну т.е. одинаково работает, но вместо определения переменной объявляет функцию.
Или так:

int a(10); // работает
MyStruct b(10); // работает

если завести у MyStruct конструктор с целочисленным параметром.
Если серьёзно, то в чём проблема-то?

Дело в том, что указанный слева квалификатор const относится к правой половине спецификации типа до первого модификатора.
const char& - ссылка на константный символ. Квалификатор - const, модификатор - &.
const char* - указатель на память константного символа. Квалификатор - const, модификатор - *.

При этом, указанный справа квалификатор const относится ко всей части спецификации типа левее, включая все модификаторы.
char* const - константный указатель на память символа.
const char* const - константный указатель на память константного символа.
char* const * - указатель на память константного указателя на память символа.
char& const существовать не может, т.к. квалификаторы не применяется к ссылкам. Тут будет ошибка трансляции.

И при чем же здесь constexpr? Просто constexpr всегда относится только ко всей спецификации типа со всеми модификаторами.
const char* - указатель на память константного символа.
constexpr char* - константный указатель времени компиляции на память символа. Тут нет ошибки, память символа тут считается модифицируемой.

И если объект с типом constexpr char* получит характеристику ODR-used [?], то после трансляции кода это будет уже объект с типом char* const. Вот так.
В то же время, строковые литералы имеют тип const char[N], т.е. статически определенный массив константных символов. Такой тип можно привести только к типу const char*.

В результате, чтобы правильно определить константный указатель времени компиляции на память константного символа, нужно тип определить как constexpr const char*.
И const в этом месте никакого прямого отношения к constexpr не имеет.

Доступ к диску на уровне блочного устройства можно получить, открыв специальный файл "\\.\PhysicalDrive0"

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

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

Сохраняйте время последнего запуска в файле или реестре (windows). И при новом запуске программы считывайте время оттуда.

Нужно понимать принципиальную разницу подхода:

apt - установка из маленьких пакетов, вместе образующих большую и сложную систему, при этом софт может массово совместно использовать одни и те же файлы и библиотеки, благодаря чему экономится место на диске, оперативная память итд итп. Надо понимать, что apt - это пакетный менеджер для определённого вида пакетов (deb), хотя в своё время существовал вариант для rpm (может и сейчас существует, просто смысла в нём мало после появления yum).

snap - установка большого приложения со всеми зависимостями, которые никак не использует остальной софт на этом же компьютере. Отсюда тратится лишнее место на диске и в оперативной памяти. Зато никаких проблем с зависимостями, плюс snap работает в любых системах и не завязан на конкретный менеджер пакетов и собственно пакетный формат.

snap по большому счёту часто используют для установки тяжёлых приложений, которые может бысть сложно опакетить, особенно учитывая разнообразие присутствующих в мире дистрибутивов (debian/ubuntu и их клоны) разных версий. В то время как большинство штатного общеиспользуемого софта чаще распространяют в виде пакетов, идущих в составе дистрибутива или отдельно (в том числе в виде разных собранных под разные варианты систем пакетов).

if (!a)	{
    a->s = s;
    cout << 5;
    return a; //ошибка, не возвращает указатель на обьект класса
}

У вас тут a==NULL - пустой указатель. Вы пытаетесь его члену что-то присвоить (то. что программа не упала - вам дико повезло). потом вы возвращаете этот же пустой указатель.

Вам надо создавать новый объект через new в этом случае.