The challenge is that you need a way to get a &mut to every Value in the HashMap with a single call to the HashMap, or else the compiler can't prove that no two overlapping &mut Value are returned.
Using unsafe to work around this would be unsound too, e.g. if hashes collide, a value for which a &mut Value was already returned may need examined to test for equality in get_mut, but that would be an aliasing violation. (That's also not as far fetched as you might think.)
I think you'll have to redesign things unless you want to collect all the &mut Value in arbitrary order and then painfully sort them based on your Vec<Key>.
Are you aware that indexmap has two removal methods? swap_remove disrupts the order in constant time, and shift_remove preserves total order in linear time.
The values in positions are indexes into data. Now, your iter_mut() can be implemented in terms of std::slice::IterMut. However, this does mean that the contents of positions have to be updated whenever anything moves in data. You can keep these moves lower by allowing data to be sparse (i.e. Vec<Option<(Key, Value)>>), though that's its own tradeoff.
By the way, there is no need to make three separate reply posts If you select the text you are responding to and click the "Quote" button that pops up, you can put three linked quotes in one post, and it will be easier to read your responses with context.