да нет. Здесь последнейший

Тогда не должно быть проблем хранить нормальный ключ

маппинг в моём примере не может владеть этим объектом by design — он где-то в другом классе

Часто ли встречается на практике баг, когда в качестве ключа маппинга используется указатель на объект, но элемент маппинга не удаляется, когда объект удаляется. Создаётся новый объект и проверяется, есть ли для него в маппинге элемент. Иногда аллокатор переиспользует участок памяти старого, только что удалённого, объекта. Ему ставится в соответствие старое значение из маппинга. Вот здесь и случается крэш какой-нибудь. Прям антипаттерн какой-то — использовать в качестве ключа невладеющий указатель.

Часто ли встречается на практике баг, когда в качестве ключа маппинга используется указатель на объект, но элемент маппинга не удаляется, когда объект удаляется. Создаётся новый объект и проверяется, есть ли для него в маппинге элемент. Иногда аллокатор переиспользует участок памяти старого, только что удалённого, объекта. Ему ставится в соответствие старое значение из маппинга. Вот здесь и случается крэш какой-нибудь. Прям антипаттерн какой-то — использовать в качестве ключа невладеющий указатель.

надо кастомный компаратор просто заводить, который разыменовывает сравниваемые указатели (если можно) и уже объекты сравнивает их компаратором

видел вот такой совет на стековерфлоу от какого-то старого инженера:
std::unordered_map<void*, void*> — что может быть лучше? ))

только std::unordered_map<void*, bool> разумеется

То есть идиотизм -- достаточно массовое явление, но не часто оно пересекается с использованием std::map или аналогов.

Пару месяцев назад фиксил такой баг. Наоптимизировали воспользовавшись string_view, который указывал в контейнер, который в свою очередь при ресайзе менял адреса элементов. Код писал совсем не дурак, хотя у меня и есть некоторые разногласия с автором.