bimap-rs VS heapless

Your requirements may be slightly different, but you could take a look at how e.g. bimap does it.

`multi_index_map` is designed to allow storage and retrieval of data through multiple indexes, along the lines of in-memory relational database. This is useful in a few situations, notably when you want to implement structures like a bi-directional map (ie. searchable either for key or value), or sets with multiple iteration orders. There exist great crates for bi-directional maps already eg. [bimap-rs](https://github.com/billyrieger/bimap-rs/), however MultiIndexMap goes further and removes the distinction between key and value, such that as many keys as necessary can be added and searched for. Multiple iteration orders can be specificed using multiple `ordered_unique` keys, and iterating by these keys. Non-unique keys are also supported, so more than one element can be retrieved from a single lookup. This crate was inspired by [Boost's C++ Multi-Index Containers](https://www.boost.org/doc/libs/1\_80\_0/libs/multi\_index/doc/index.html), but completely redesigned for a more idiomatic Rust API. We've got to v0.4.0 now, and the main features have been fleshed out enough for me to feel comfortable announcing this. There is still lots to do, and I'm welcoming PRs from anyone who wishes to contribute. The [Future Work](https://github.com/lun3x/multi\_index\_map#future-work) section explains the general direction I am planning on going in.

> we did not have Vec because we were no-std + stable so we literally had to use arrays

It's true that Vec isn't available in a no-std context, but don't think it follows that arrays are the only other option - see heapless for one example: https://github.com/japaric/heapless

I also agree with some of the ancestors: the post seems to say that the Rust language couldn't handle arrays with more than 32 elements, and (as someone who's written a fair bit of no-std Rust before const generic) that doesn't seem right. At first, this did seem awkward to me as well, but in practice I haven't found it to be a significant limitation. Was there a particular scenario where it wasn't feasible to wrap a >32 element array in your own type and implement Default on it?

It's happening

heapless has both SPSC and MPMC channels that work on embedded