Учитывая объект ржавчины, можно ли обернуть его так, чтобы множественные ссылки и изменяемая ссылка были разрешены, но не вызывали проблем?
Например, Vec с несколькими ссылками и одной изменяемой ссылкой.

Тип, который вы ищете, это RefCell, но прочтите, прежде чем спешить!
Rust — это язык с единым владением. Так будет всегда. Это именно то, что делает Rust таким потокобезопасным и безопасным для памяти. Вы не можешь полностью обходите это, если не считать обертывания всей вашей программы в unsafe и использования исключительно необработанных указателей, и если вы собираетесь это сделать, просто напишите C, поскольку вы больше не получаете никаких преимуществ от использования Rust.
Итак, в любой момент в вашей программе должна быть либо одна вещь, записывающая в эту память, либо несколько вещей, читающих. Это основной закон единоличного владения. Запомни; вы не можешь обходите это. То, что я собираюсь сказать, по-прежнему следует этому правилу.
Обычно мы применяем это с помощью наших подписей типов. Если я возьму &T, то я просто псевдоним и не буду на него писать. Если я возьму &mut T, то никто другой не сможет увидеть, что я делаю, пока я не потеряю эту ссылку. Обычно этого достаточно, и если мы можем, мы хотим сделать это таким образом, поскольку мы получаем гарантии во время компиляции.
Но это не всегда так работает. Иногда мы не можем доказать, что то, что мы делаем, в порядке. Иногда у меня есть две функции, содержащие, якобы, изменяемую ссылку, но я знаю, что из-за некоторых других гарантий, о которых Rust не знает, только одна будет писать в нее одновременно. Введите RefCell. RefCell<T> содержит один T и претендует на то, чтобы быть неизменным, но позволяет вам заимствовать вещь внутри либо изменчиво, либо неизменно с помощью try_borrow_mut и try_borrow. Когда мы вызываем одну из этих функций, мы получаем значение, похожее на ссылку, которое может считывать (и записывать в случае изменяемых данных) исходные данные, даже если мы начали с &RefCell<T>, который не является изменяемым Смотреть.
Но основной закон остается в силе. Обратите внимание, что эти функции try_* возвращают Result, т. е. они могут завершиться ошибкой. Если две функции одновременно попытаются получить try_borrow_mut ссылки, вторая потерпит неудачу, и ваша работа — справиться с этой возможностью (даже если «сделать это» означает panic! в вашем конкретном случае использования). Все, что мы сделали, это перенесли правила единого владения из времени компиляции во время выполнения. Мы не избавились от них; мы только что изменили ответственных за их соблюдение.
Кроме того, обратите внимание, что если вы используете unsafe, чтобы «обойти» единоличное владение, ваша программа все равно будет неправильной, если вы просто обходите правила вслепую. unsafe просто означает «Я проверил, что этот код соответствует правилам, поэтому компилятору это не нужно». Компилятор по-прежнему будет предполагать, что правила были соблюдены, и за пределами блока unsafe будет использовать это предположение при генерации кода. Если все, что вы делаете в unsafe, — это обход правил владения, это, скорее всего, приведет к неправильному codegen.
Возможно
RefCell?