Интересно Вы мыслите), но неверно.
Если велосипедист не затормозит на повороте - улетит в кювет), что и бывает с автомобилями в реальной жизни при гололёде.
Поворотом руля, нажатием на тормоз велосипедист как раз управляет силой сопротивления за счет трения, которая зависит кроме всего прочего от ширины соприкосновения поверхностей вдоль направления движения. Точно также конькобежец управляет скоростью и направлением движения только за счет поворота лезвия конька.

Если всё происходит в невесомости в открытом космосе, то именно правый вариант является правильным.)

А так велосипедист имеет еще сопряжение с дорожным покрытием, относительно которого как минимум действует сила трения (качения или скольжения), зависящая от кучи разных характеристик (скорость движения, коэффициент сцепления и т.п.). При этом у велосипеда обычно два колеса, каждое из которых скользит и катится по разному. А если велосипедист ухватится еще за точку опоры для поворота? И т.д. И опять же ветер в лицо дует, значит есть ещё сила сопротивления и т.д.

Если нужна реальная физика, привлеките к работе физика-механика, который распишет физические модели поведения объектов и явлений в упрощении, достаточном для решении Ваших задач.
Ну или придется осваивать физику самостоятельно).

Если известна целевая траектория движения, то всегда можно рассчитать скорость и ускорение в любой момент времени.
Если же требуется управление какими-то характеристиками объекта со стороны пользователя во время игры, то без модели управления здесь не обойтись.

На пальцах попробую передать мысль)
Есть два вида объектов безвольные (с отсутствующей внутренней моделью поведения) и своевольные (у которых есть внутренняя модель поведения).
На первые действие оказывается только с помощью внешнего воздействия - применения сил и др.
Вторые к внешнему воздействию могут добавить внутреннее. То есть если что-то должно самостоятельно двигаться по кругу, то пусть оно и старается двигаться).
Если самостоятельное движение должно быть на что-то похоже, то это "похоже" нужно представить в виде внутренней модели, которая управляться может какими-то параметрами (специфичными для данной модели). Суперпозиция внешнего воздействия с внутренним и даст желаемое поведение.

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

Модель поведения можно и захарткодить. Необязательно переходить к скриптам. А пользователю необходимо дать возможность управлять моделью удобным для него способом.
Если необходимо выдержать определенную траекторию движения, например, пройти четко по кругу, а не по эллипсу. То пользователь ни в жизнь не подберет такой набор сил, которые нужно применить к объекту. И тем более не сможет заранее оценить, возможна ли в принципе такая траектория для данного "товарища". А вот модель поведения - может и силы рассчитать нужные, и приложить их в нужный момент, и максимально близкую траекторию движения к заданной выдержать.

Управляете, например, автомобилем, Вы ведь силы не задаете? Руль крутите и педали жмете в зависимости от текущих характеристик движения.


Можно честно подходить к моделированию физических явлений, используя физические модели с разными упрощениями и допущениями. Как правило это трудоемко и связано с решением каких-нибудь дифференциальных уравнений (все те же законы сохранения). А можно использовать результаты натурных экспериментов - информация с датчиков или их приближения в виде сплайнов, изи кривых и т.п. В инженерных программах, где важна точность используют решение уравнений, в играх, где важна похожесть на правду, - используют приближения по натурным измерениям или их вообще аниматор задает, чтобы добиться какого-нибудь художественного эффекта.

 
И здесь оказывается, что пользователю не поведением каких либо бездушных тел нужно управлять, а группой "товарищей" 

Так вот "товарищи" сами по себе обладают поведением и возможностями прикладывать к себе силы по мере необходиомости для достижения поставленных целей. Применение к ним модели сил со стороны пользователя выглядит весьма странно - как некое божественное вмешательство).

Обычно, для "товарищей" реализуется индивидуальная модель поведения с заданными ограничениями (скорость, ускорение и т.п.), а пользователем задаются параметры для реализации этой модели. Например, двигаться в из точки А в точку Б с 50% от физических возможностей "товарища", чтобы не сильно устать)), или не много топлива потратить, или других ресурсов, расход которых определяется моделью поведения.

Если рассматривать корректное физическое движение объектов в пространстве, то здесь требуется учитывать фундаментальные законы сохранения - массы, импульса и энергии. Вся теория физики проистекает из них. Управлять значением силы для описания соударений, как минимум неудобно, так как при абсолютно упругом столкновении имеется разрыв в функции скорости от времени, а функция ускорения от времени стремится в бесконечность (производная по времени функции скорости от времени). Фактически, возникающая в момент соударения сила является следствием свойств самих тел и их кинематических характеристик движения. Она принципиально не может быть задана заранее для любых столкновений, так как в каждом случае она будет своя.

Пользователь должен иметь возможность задавать массу объекта, силы действующие на него в пространстве - точечное воздействие или потенциальное поле.
А для моделирования столкновения объектов задавать процент потерь на диссипацию энергии, и рассчитывать кинематические характеристики тел после столкновения в соответствии с уравнениями сохранения.

Айтем грохнуть может только родительский айтем. ItemPointer в данном случае не должен предоставлять такую возможность.

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

Там случайно в методе createChild не ошибка?

C++ (Qt)
    ItemPointer createChild(qsizetype row = -1)
    {
        insert(row == - 1 ? childCount() : row, std::make_unique<Derived>());
        return ItemPointer(m_children.back().get());
    }
 

При любом row возвращается последний из элементов. Не должно быть хотя бы так?

C++ (Qt)
    ItemPointer createChild(qsizetype row = -1)
    {
        insert(row == - 1 ? childCount() : row, std::make_unique<Derived>());
        return child(row);
    }
 

Тогда можно так

C++ (Qt)
using Items = ::std::list< Item >;
using ItemForIndex = ::std:vector< Items::iterator >
 
Items m_items;
ItemForIndex m_item_for_index;
 

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

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


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


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

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

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

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


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


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

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


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

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

Насколько оправдано использование вектора здесь? Разве нужен рандомный доступ?
Преимущества std::list и его итераторов, которые не портятся со временем), здесь явно.

Смущает только использование не быстрого поиска дочернего элемента

C++ (Qt)
const auto pred = [item](const ItemUniquePointer &p) { return item.get() == p.get(); };
const auto it = std::find_if(m_children.begin(), m_children.end(), pred);
 

Можно немного изменить ItemObserverPointer - реализовать его через итератор листа, с помощью которого и удалять дочерний элемент без всякого поиска.

Как раза хотел о том же сказать). Вот же пример иерархии tree-example, который мы разбирали. Возьмите в качестве значения unique_ptr< QObject> и будет счастье. К слову, эта реализация у нас хорошо зашла для широкого использования.

Если честно - полное отсутствие каких-либо мыслей)). Это какое-то изнасилование unique_ptr ( использовали child->setParent(this); и выбросили child.release(); ).
Нужно сначала понять преследуемую цель применения здесь умных указателей. Если для внутреннего использования, чтобы с исключениями можно нормально работать было - это одно; если добавить заплатки для тех, кто использует умные указатели - другое; если еще что-то - то третье.