От вж QueryParams вообще ничего не зависит. Начну с поверхностного уровня.

Во-первых, куда денется старое значение в self.users после переприсваивания? Никуда. Оно дропнется.
Раз оно дропается, на что указывают ссылки на юзеров в хэшмапе? Ни на что, они провисли.
Во-вторых, можно ли просто очищать хэшмапу перед тем, как класть ссылки на новых юзеров? Конечно же можно, но дело не в этом. Лайфтаймы выражают довольно простые штуки на уровне типов и не учитывают особенности хранения чего-то там в разных контейнерах. Они строго в комптайме и до тупого простые. Конечно, есть и сырые указатели, есть и ансейф каст сырых указателей в ссылки с любым лайфтаймом. Тут приходим к третьему вопросу.
Учитывая сказанное, нормально ли, соблюдая инварианты, хранить ссылки внутрь вектора? Нормально, но требуется очень тонкий контроль со стороны. Например, нельзя взять и добавить в существующий вектор новые элементы, он может реаллоцировать и заставить ссылки провиснуть. Очень опасно добавлять их по идее в принципе даже с учётом ёмкости, потому что возникают страшные компиляторные понятия рестрикт указателей с провенансом (мут ссылки именно рестрикт) и концепция stacked borrows. Нужно, вдобавок, соблюдать такую штуку, называемую exception/panic safety. Вкратце, далеко непростые вещи. Сами ошибки гораздо проще станет допустить, и они будут не на уровне логических багов, а неопределённым поведением.
tl;dr: самоссылающиеся структуры довольно опасны.

О. теперь понял) спасибо

Если я правильно понимаю. То происходит вот так : 1) С users может произойти что угодно (дропнуться, реаллоцироваться, етц) 2) В это же время в хешмапе у нас находится лайфтайм, который обещает компилятору, что этот объект будет жить такой-то скоуп. 3) However, нигде нет гарантии того, что объект в векторе .users. Будет жить столько же, сколько и объект в хешмапе (к примеру, вектор реаллоцируется). 4) Компилятор шлёт нас куда подальше. Что-то упустил ?