Improve (?) Erlang mapping

syndicate/mc/preserve.md

@@ -871,19 +871,23 @@ should both be identities.
  - `Boolean` ↔ `true` and `false`
  - `Float` and `Double` ↔ floats (unsure how Erlang deals with single-precision)
  - `SignedInteger` ↔ integers
- - `String` ↔ tuple of `utf8` and a binary
+ - `String` ↔ pair of `utf8` and a binary
  - `ByteString` ↔ a binary
- - `Symbol` ↔ the underlying string converted to an Erlang atom, if
-   some kind of an "unsafe" mode is set on the decoder (because Erlang
-   atoms are not GC'd); otherwise perhaps a tuple of `symbol` and a
-   binary of the utf-8
- - `Record` ↔ a tuple with the label in the first position, and the fields in subsequent positions
+ - `Symbol` ↔ pair of `atom` and a binary
+ - `Record` ↔ triple of `obj`, label, and field list
  - `Sequence` ↔ a list
- - `Set` ↔ a `sets` set (is this unambiguous? Maybe a [map][erlang-map] from elements to `true`?)
+ - `Set` ↔ a `sets` set
  - `Dictionary` ↔ a [map][erlang-map] (new in Erlang/OTP R17)
 
-This is an unsatisfactory mapping: it conflates `"hello"` with `(utf8 #"hello")`,
-and `true` with `#t`.
+This is a somewhat unsatisfactory mapping because: (a) Erlang doesn't
+garbage-collect its atoms, meaning that (a.1) representing `Symbol`s
+as atoms could lead to denial-of-service and (a.2) representing
+`Symbol`-labelled `Record`s as Erlang records must be rejected for the
+same reason; (b) even if it did, Erlang's boolean values are atoms,
+which would then clash with the `Symbol`s `true` and `false`; and (c)
+Erlang has no distinct string type, making for a trilemma where
+`String`s are in danger of clashing with `ByteString`s, `Sequence`s,
+or `Record`s.
 
 ### Python