Some map operations have been optimized by changing the internal sort order of atom keys.
This changes the (undocumented) order of how atom keys in small maps are printed and returned by maps:to_list/1 and maps:next/1 . The new order is unpredictable and may change between different invocations of the Erlang VM.
Finally we get rid of the “you shouldn’t rely on their order but…”. Proven to be unstable
In the lists module, the zip family of functions now takes options to allow handling lists of different lengths
Hopes up this one trickles down to Elixir. Recently had to write my own implementation of zip due to different length. Not a biggie, but was surprised it wasn’t in stdlib. (I would swear I once saw the option to ‘keep_rest: true’ or alike)