Конечно, хотелось бы видеть теоретическое обоснование, а не толкование стандарта. А так ... можно и поспорить))).
Хотя, где я, и где Herb 

Не будем не рассматривать возможные специализации функции move, возьмем только стандартную реализацию.
И пройдемся по некоторым положениям свежака).


Действительно, простое применение функции move никогда не делают никакой объект инвалидом). Можно хоть миллион раз вызвать move.
Работают здесь по настоящему либо конструктор, либо оператор перемещения (такие специальные для работы с rvalue значениями).


Как видно, критерием автоматического применения move является знание, что экземпляр объекта не используется снова. Как правило, это временные объекты, которые разрушаются сразу после перемещения. Использование move является принудительным преобразованием к виду rvalue, подобного временному объекту, который после операции перемещения применять в дальнейшем не предполагается.

Если разделить экземпляр объекта на две составляющие - значение и токен (то, посредством чего можно обратиться к значению), то можно заметить, что rvalue - это значение без токена, а lvalue с токеном. Логически операция move подразумевает перемещение значения из одного места в другое, и если токен (а не значение) после извлечения из него значения станет инвалидом в чем здесь проблема? Если от донора к акцептору пересадить сердце, останется ли жив донор?

Herb рассматривает пример с IndirectInt

Здесь поменяны местами причина и следствие. Утверждение, что класс некорректен следует из утверждения, что некорректным является рассмотренное поведение. Интересно, а что будет, если рассмотреть такой вариант?


Еще одно утверждение


не является правдой! Пользователь функции, вызывающий f( a, b ), всегда знает перемещались ли a или b до момента вызова. Разработчик же функции не обязан контролировать существование значений у неопциональных параметров.

Ну и корень всего)


Собственно, из такой формулировки стандарта делаются все выводы о некорректности той или иной реализации выше. При этом такая логическая модель перемещения (первичная по отношению к языку программирования) является противоречивой, в отличие от модели EoP. При этом пример not_null именно и показывает на практике противоречивость модели. Следовательно требуется корректировка стандарта. При этом многие пользователи языка и разработчики статических анализаторов сделали вывод о том, что лучшей практикой является считать, что перемещенный экземпляр объекта лучше не трогать).

А так это похоже на известный анекдот - "Ежики плакали и кололись, но продолжали жрать кактус".

Исходя из требования модели или особенности технической реализации?

Одно другому не мешает . Те же самые умные указатели std при перемещении "зануляются" в реализации, что соответствует переходу в "пустое" состояние для optional-like объекта. И выглядит это вполне логично:

C++ (Qt)
#include <memory>
#include <iostream>
 
class Label
{
public:
    using Caption = std::unique_ptr<std::string>;
 
    Label() = default;
    explicit Label(Caption caption) noexcept
        : m_caption{std::move(caption)}
    {}
 
    Caption releaseCaption() noexcept
    { return std::move(m_caption); }
 
    void print() const
    {
        std::cout << "Caption: " << (m_caption ? *m_caption : "[none]")
                  << std::endl;
    }
 
private:
    Caption m_caption;
};
 
int main()
{
    Label label{std::make_unique<std::string>("Hello!")};
    label.print();
    label.releaseCaption();
    label.print();
}

Как будет выглядеть Label::releaseCaption(), если придётся вручную переинициализировать m_caption?

"C++ Move Semantics - The Complete Guide" now Feature Complete. Всё, что нужно знать про перемещение. Всего-то страниц 200 .

Про отношения между объектами в картинках: unique_ptr, shared_ptr, weak_ptr, or reference_wrapper for class relationships.