We briefly discussed in the maintainers' meeting of 2022-04-07, the deepEqual file in the harness has some problems in its semantics and we should at least encourage new tests not to use it, while working out a better way to provide that functionality.

I've taken a look at what uses it and identified three categories:

1. Comparing two arrays with primitive values in them ­— it seems to me this can be replaced wholesale by compareArray, which is clearer and more fit for purpose anyway.
2. Comparing two objects with primitive values as their keys, where order of assignment doesn't does matter.
3. Comparing two arrays with non-primitive values in them.

Here are the places where it's currently used:

• Error/constructor.js - (1) - I've changed this already in Replace deepEqual with compareArray #3475
• RegExp/match-indices/indices-array-non-unicode-match.js, indices-array-unicode-match.js - (3)
• Temporal/Calendar/prototype/mergeFields/basic.js, iso8601-calendar-month-monthCode.js, non-string-properties.js - (2)
• Temporal/PlainYearMonth/prototype/add/calendar-datefromfields-called.js, subtract/calendar-datefromfields-called.js - (2)
• Temporal/ZonedDateTime/prototype/getISOFields/negative-epochnanoseconds.js - (2)
• DateTimeFormat/prototype/formatRangeToParts/temporal-objects-resolved-time-zone.js, formatToParts/temporal-objects-resolved-time-zone.js - (3)

Providing alternatives for the remaining uses could be an interesting first test of our RFC process once I have come up with a proposal for that.