You've covered a lot here, but just want to comment on a few things. Factory functions can return objects that have a prototype just the same as "new", there i

You've covered a lot here, but just want to comment on a few things. Factory functions can return objects that have a prototype just the same as "new", there is no inherent reason object constructors should require "new". Given that most of modern, idiomatic JS relies on factory functions, it seems very inconsistent to me to then randomly require invoking "new" to construct an object. Why not simply Set([1, 2, 3])? The noise comes when you have a nested expression with random "new" statements sprinkled in which disrupts the flow. Though I agree that overly complex expressions are an anti-pattern My underlying point is that "new" does not provide any clarity, given that objects are created and returned all the time without "new", so represents an inconsistency in design to me. The presence or absence of "new" basically tells you nothing, except implying that the object likely has prototype functions. But whether or not they are prototyped is more of an implementation detail anyway. I agree with you that most of Temporal has factory functions that obviate "new". To your point on performance of closures, this isn't going to materially matter for majority of use cases. Yes, prototype is more efficient than closures functions, but benefits of prototypes can also be achieved through separation of data and function (singleton utility functions that operate on data). Also syntax sugar for prototype could have been done in an (IMO) more consistent way through some syntax addition to functions rather than creating class. Generally modern userland code shouldn't really be using prototype and "this" anyway, as "this" has tons of footguns in JS, and I would guess majority of developers don't understand the intricacies of "this" when passing functions around, or when using arrows vs classical function declarations.