Could the ambiguous unflatten() issue be solved by adding type hints?

[pnck]

There have been some relevant issues:
#1575
#1989
#2123

But it seems nobody suggested introducing some typing annotations or hints, like this:

{"0":"v0","1":"v1"} // flatten() => {"@O/0": "v0", "@O/1": "v1" }
["v0",v1"] // flatten() => {"@A/0": "v0", "@A/1": "v1" }

Or separate the type info to another item:

{"obj":{"0":1, "1":2}, "list":[1,2]} // flatten() => {"/obj": "@object",  "/obj/0": 1, "/obj/1": 2, "/list":"@array", "/list/0": 1, "/list/1": 2}

Or a new child item:

{"obj": {"0": 1} } // flatten() => {"/obj/@object": null , "/obj/0": 1}

What do you guys think of this?

[nlohmann]

Any of the proposed schemes would change the on-the-wire format that flatten() produces, which is a breaking change for anyone currently round-tripping flatten()/unflatten() output, and none of the referenced issues (#1575, #1989, #2123) settled on an approach either. This seems like a genuine ambiguity worth solving eventually, but it likely needs an opt-in flag or a new pair of functions (e.g. flatten_typed()) rather than changing default behavior, to avoid breaking existing consumers.

---

This reply was drafted by Claude Code on behalf of @nlohmann, as part of a review of open discussions.