Ah, I get what you mean. Yep, that did catch me out. My inclination though is to reach for map! instead as it has no context and potentially doesn't require a preset list of fields, or another way of designating the rule (e.g. [rule: bind 'rule 'some-other-word-in-the-parent-context-that-isnt-in-the-object]—not ideal and a more nuanced constructor would be better in this instance). This goes back once again to thinking about what objects are for—1) single use, code-grouping objects such as this vs. 2) prototypes representing things in the classical object-oriented sense—which I'd still prefer to see prioritized. Again, I'm sympathetic to the need for different constructors, but still have reservations about the implications of my/method as a solution to binding when cloning. Anyways, this is more a response to that topic than this one.
Specific usage of mark here is a behavioural legacy and a mistake, the convention I'm looking to use here would be state/mark. I'm not sure I see the state basket as being heavy handed, I think it's a reasonable response to the complexity of what I'm trying to achieve. Could well also be my familiarity bias too, but for now it's workable as a means to explore the Parse Machine concept to a conclusion.