теперь нужен jasync с итерапшн поинтами

Раз уж зашла речь про неймспейсы и использование unqualified имен типов подскажите у кого какие лучшие практики с nested namespaces.
Несколько раз сталкивался с такой проблемой:

// foo.h
namespace my { class foo; }

// bar.h
#include "foo.h"
namespace my::internal
{
  void bar( foo& ); // << unqualified name. По задумке автора это my::foo
}

// internal/foo.h
namespace my::internal { class foo; }

// baz.cpp
#include "internal/foo.h"
#include "bar.h" // << а вот тут у нас odr-violation и my::internal::bar( foo& ) теперь принимает my::internal::foo

Все прекрасно компилируется, вы получаете разные лэйауты в разных юнитах трансляции для имени foo и просто какуюто кашу в памяти в рантайме, дебажится это плохо, потому что детектится проблема неочевидно, особенно на больших кодовых базах, довольно неприятные баги.
Что делать в таком случае? Всегда использовать полные имена со всеми неймспейсами даже если они в родительском неймспейсе? Это плохо контроллировать, для компилятора это валидно, а переносить поддержку этого на человека и код ревью не выглядит как что-то надежное.
Не использовать nested namespaces?

@antoshkka userver в опенсорс когда заглянет?))

// foo.h
namespace my { class foo; }

// bar.h
#include "foo.h"
namespace my::internal
{
  void bar( foo& ); // << unqualified name. По задумке автора это my::foo
}

// internal/foo.h
namespace my::internal { class foo; }

// baz.cpp
#include "internal/foo.h"
#include "bar.h" // << а вот тут у нас odr-violation и my::internal::bar( foo& ) теперь принимает my::internal::foo

не писать в nested классы из родителя

Сложно контроллировать такое, это могут сделать разные программисты из разных команд. Классы разные, просто так совпало что имена одинаковые, но fq-name разное, поэтому на уровне анализа никаких конфликтов нет

мы работаем над этим
Процесс идёт, но очень медленно

мы тут все очень ждем) и готовы помочь, если требуется..)

Может ли поток разблокировать мьютекс, который заблокировал другой поток?

нет, не делайте так
POSIX запрещает, C++ запрещает https://en.cppreference.com/w/cpp/thread/mutex/unlock

std::mutex::unlock The mutex must be locked by the current thread of execution, otherwise, the behavior is undefined.

для этих целей используется condition_variable

Или семафор.

тут дело не в теории, а что будет на практике?

на практике сразу свалится

Это UB. На этом разговор окончен.

К сожалению, нет.

на практике может работать, но может свалиться в любой момент

На практике можешь послать потоку сообщение чтоб он  сам закрыл мьютекс

По хорошему так и надо