A Logos sorted map: (sorted-map ...) / (sorted-map-by cmp ...).

Backed by a plain sorted association list (entries: [{key, value}, ...], kept in cmp-order at all times), the same "boring, obviously correct, O(n) per op" tradeoff already made for logos.seq's sort/distinct (see that module's own moduledoc note) rather than a balanced tree -- correctness, not asymptotic performance, is what a Logos script's collection sizes actually need. cmp is a plain 2-arity Elixir function (term(), term() -> :lt | :eq | :gt), never a raw Logos closure stored directly: Logos.Primitives builds it once at construction time, either from the shared default compare ordering or by wrapping a caller- supplied Logos comparator function via Logos.Eval.apply_fn/3 (see Logos.Primitives' sorted-map/sorted-map-by primitives) -- this module itself stays free of any Logos.Eval/Runtime coupling, the same purity Logos.Vector/Logos.Record already have.

A genuine new runtime value type (mirroring Logos.Vector), not a record-based workaround: type-of returns :sorted-map (distinct from a plain map's :map), and Logos.Primitives' get/assoc/dissoc/ Logos.Printer/= all get dedicated clauses -- see each for how a sorted map otherwise behaves exactly like an ordinary one (content-equal to a hash-map with the same entries, prints as {...} in sorted order, no dedicated reader syntax, matching real Clojure: (pr-str (sorted-map :a 1)) reads back as an ordinary hash-map too, not a sorted one).