Ограничения std :: copy более мягкие, чем std :: memcopy?

С учетом на проблемы copy vs. memcpy vs memmove ^{(отличная информация здесь, кстати.)}, я читал, и мне показалось, что в отличие от того, что в разговорной речи говорится, например, на cppreference _{Примечание. После взятия этой цитаты memcpy был изменен на memmove.} -

Примечания

На практике реализации std::copy избегают множественных назначений и используют функции массового копирования, такие как std::memcpy, если тип значения TriviallyCopyable

- std::copy (или std::copy_backward) нельзя реализовать в терминах memcopy, потому что для std::copy только начало целевого диапазона не должно попадать в исходный диапазон, а для memcpy все диапазоны не должны перекрываться.

Глядя на реализацию Visual-C ++ (см. Заголовок xutility), мы также можем заметить, что VC ++ использует memmove, но этот теперь имеет более мягкие требования, чем std::copy:

... Объекты могут перекрываться: копирование происходит так, как если бы символы были скопированы во временный массив символов, а затем символы были скопированы из массива ...

Таким образом, может показаться, что реализация std::copy с точки зрения memcpy невозможна, но использование memmove на самом деле является пессимизацией. (крохотная пессимизация, возможно, неизмеримая, но все же)

Возвращаясь к вопросу (ам): Верно ли мое резюме? Это где-нибудь проблема? Независимо от того, что указано, существует ли вообще возможная практическая реализация memcpy, которая также не соответствовала бы требованиям std::copy, т.е. существуют ли memcpy реализации, которые нарушаются при частичном перекрытии диапазонов как разрешено std::copy?