@DerekNonGeneric I'm not sure what exactly you're looking for, but here's this:

• operator is probably far too limiting to be of use past trivial comparisons such as ===, >, !==, etc. Other comparisons such as regex matches, deep object equivalence, deep property comparisons or compound assertions won't have much use for it.
• Many of the mentioned properties in the ecosystem's AssertionError implementations are framework-specific. It's clear from the proposal that this is understood, but bears repeating.
• IMO contextual information about the difference between actual and expected is absolutely necessary for any framework to make use of an AssertionError. I believe this was the intent behind operator, but again, I think that's insufficient. For example, we could be checking that object foo and object bar are not strictly equal. operator may be sufficient for this case, but without anything else, it cannot be expressed by just actual and expected--these properties may be useless at best and misdirection at worst. So it's the responsibility of whatever is throwing the AssertionError to put enough information in there that the consumer (a test framework perhaps) can display a representation. For that reason, a free-form difference property makes sense to me. This could be structured data or just a string; it will probably be difficult if not impossible to define/standardize a structure which would represent any "assertion" which can fail. At any rate--something else is needed.
• In the case of "compound" assertions (e.g., array foo contains object bar and has length 4), an assertion library may make both of these checks; if the first fails, it may not short-circuit the assertion. These failures would be combined into a single AssertionError then thrown. Is it possible to leverage the newish cause prop here, though it looks more like a linked list than "(potentially) multiple causes", so maybe not applicable?

("assertion libraries" above also means "assertion subsystems of testing frameworks")