Feeback - Syntax and Behaviors

**Naming** Not every programming term is clear, but `Composites` to me is not clear on implied behavior. Based on the functionality described so far, I'd recommend any of the following names: ``` if class from language: par (latin for equal, equal-sized, well-matched) collage semblance congruent congruous consonant from academia (LLM assisted; I verified meaning): Isomorph Bijective Invariant Allotrope Anagram Affine if method: Object.imitable() Object.isomorphic() Object.congruous() ``` **Class vs Method** Considering this proposal is largely about modifying current behavior (equality algorithm) on a per-object basis, there's small precedence with `Object.freeze` and `Function.bind` who also change default behaviors. I would argue this is a flag/slot on the object to be utilized by others and should be set via method, as described in [this](https://github.com/tc39/proposal-composites/issues/11#issuecomment-2804445614) post. This allows a developer to leverage the current equality early on and then at some point downstream decide to change equality behavior. This is not anti-foresight, it's just giving developers choice. ```js myArr.composite(); myObj.composite(); // Object.freeze cannot be undone, but perhaps myObj.composite could be, via passing a boolean. ``` **Composite Properties Enumerable** The language for this section ([here](https://github.com/tc39/proposal-composites?tab=readme-ov-file#are-keys-enumerable)) is unclear, whose keys are enumerable? The Composite's internal value obj/arr? If it's `Composite` itself, then that clashes with the transparent operation style from the rest of the proposal, since being able to do `key in/of obj` is very common. **Obscured typeof / constructor / instanceOf** I've written recursive algorithms where I must figure out what the turn value's 'type' is as the next action depends on that. I absolutely do not want to have to add `isComp = Composite.isComposite( turnValue );`. For cases like serialization it may be moot, as I would care about the contents, but for cloning or interrogation it would be preferred to have `constructor` or `instanceOf` expose the correct type. `BigInt` and `Async Function` got their own despite being 'variants' of existing types. This is already wonky in JS, but I would try to gravitate towards consistency instead of inconsistency. **Proxy** `Proxy` has some design choices that may be relevant: - **Extraction** - I did not see any explicit language in the proposal where like `Proxy`, one cannot extract the original object from the wrapper by design. If that's desired maybe mention it. - **Set/get traps** - I'm a big fan of set/get traps, they are highly useful and I wish I didn't have to use a Proxy to have them. That said, you did not explain why "A proxy with a composite as its target is not considered a composite" [here](https://github.com/tc39/proposal-composites?tab=readme-ov-file#how-to-check-if-something-is-a-composite). If composite is highly transparent with minimal behavior change, then the interaction with Proxy should not be different from non-composites. **Final Notes** Considering this proposal is largely a commentary on the equality algorithm, I feel like it might make more sense to directly attack the problem; rather than a new *implicit* equality, propose a new *explicit* equality. Perhaps equality itself deserves a global entity with methods.