([ ({"this", "that", "and that one other thing"}): "Now I remember!" ])

Minor comment/nitpick...Using an array as a mapping key isn't likely to work well in MudOS/FluffOSif the idea is to use that key to refer to the value. This syntax is legal, but probably not useful for that.

You can probably find this in a lib, for example in situations where the mud is trying to match arbitraryinput with one thing, in which case you enter a loop and go through all the elements in the map.

MapName[({"this","that"})] (that is, a retrieval based on a constructor-specified array)

to work in any LPC variant I know anything about, because arrays (and mappings) are pointers. So in order to retrieve using an array key, you have to provide the same array as was used as a key when the value was assigned, not a different array with the same contents. This doesn't make array or mapping keys completely useless, just mostly.

Would be kinda neat though. It would give you a many-to-one mapping, which you really can't do right now. I believe it would also make mappings 100% reversable.

Right now, you can reverse a mapping (swap the keys and values), but if you have same value assigned to multiple keys, it's undefined which one will end up being the new key, and thus which old key ends up being its value.

In this case, I'm thinking of the mapping data type being able to use the contents of an array key, rather than just the pointer. If it understood that, it could fold multiple keys into the same place, and thus a reversal would work as you might expect it to.

I suspect the only places this would really find any benefit would be in database work (M:1 maps), and perhaps in parsers to be able to have a whole set of synonyms point to the same coderef or other data block.