proposal-relative-indexing-method VS proposal-accessible-object-hasownproperty

If you want to learn more, check out the MDN reference for it. You can also read the original proposal for it.

Just like every other array method, it’s type coerced. It’s a problem with all built ins, best not fracture this more in JS without a very good reason. https://github.com/tc39/proposal-relative-indexing-method/issues/40

.at()

.at() .at() method on all the built-in indexables.

For a proposal to be finalized, it needs "Two compatible implementations which pass the acceptance tests" (source). This can mean browsers but also includes transpilers like babel. Chrome - which also includes other browsers now like Edge and Opera - will often release stage 3 features publicly before finalized, and Firefox isn't usually far behind, or sometimes even first, as was the case with the currently stage 3 at() method for arrays. Safari is probably the one you have to worry about the most. They tend to be further behind, I think mostly due to their release cadence being longer. Safari, for example, doesn't yet support private methods whereas the other browsers have supported them for some time now. While private methods are stage 4, they are expected to be part of ES2022 which hasn't been published yet - the current being ES2021.

Soon we’ll get this nicer version (proposal):

Proposal hosted on GitHub explains the reasoning behind it https://github.com/tc39/proposal-relative-indexing-method

https://github.com/tc39/proposal-relative-indexing-method#rationale

Its reasons like these you're actually seeing a trend with the opposite happening within the native JS API. For example a proposal for JS that recently got approved was Object.hasOwn() which is a non-method version of Object.prototype.hasOwnProperty().

Object.hasOwn Accessible Object.prototype.hasOwnProperty()

Accessible Object.prototype.hasOwnProperty(): Proposal for an Object.hasOwn() method to make Object.prototype.hasOwnProperty() more accessible.