Alexander Plavin

`stack` should produce a KeyedArray when both the inner arrays and the outer container itself are KeyedArrays.

I think it arises because collections (include UnitRanges) are treated as multiple elements in lookup: ``` julia> KeyedArray([1, 2], a=[(1:2), (3:4)]) 1-dimensional KeyedArray(NamedDimsArray(...)) with keys: ↓ a ∈ 2-element Vector{UnitRange{Int64}}...

I don't think I ever used `UnorderedDictionary`, but always assumed it is actually "unordered", that is without any order defined, implying that the comparison should only depend on the elements...

For hash, any commutative combiner function would work – Base.Dict uses xor. Apply `hash` to all keys/values in any order, and combine with `xor`, that's it.

> yes, meaning unspecified order, much like C++ unordered_map I think C++ unordered_map is _actually_ unordered: it compares equal when the elements are equal as a set, ignoring any kind...

benchmark CI failure unrelated

changed to only accept closed intervals – they are returned by `0..1` syntax, and by far the most common kind of intervals

It's the "array vs table" confusion yet again. Tables.jl tables can be arbitrary types, and it's impossible to distinguish them from arrays (because arrays can be tables). So, any package...

Good point! Maybe that new `wraptable` can become the recommended way to go from table to KA, and also include fixes for https://github.com/mcabbott/AxisKeys.jl/issues/168 and https://github.com/mcabbott/AxisKeys.jl/issues/105 without any breaking changes.

Heh, I guess you are right, it makes sense for `set(reverse)` to allow changing the array length. PRs to fix bugs / add missing functionality like this are welcome!