> I suppose to not break existing code that implements a dispose method
Exactly. This is standard for new "magic" object members - see [Symbol.species], [Symbol.iterator], and so on. Your existing dispose() method might take arguments, or it might return a promise, or maybe you have a field called dispose that isn't a dispose() method at all. This approach is slightly less pretty, but it preserves backwards-compatibility and avoids conflicts with the many weird, decades-old JS libraries still floating around on the web.
(Also see Array#flat(), which had to be called that because some ancient libraries modified the Array prototype to add a #flatten() method... It's a mess out there.)
Exactly. This is standard for new "magic" object members - see [Symbol.species], [Symbol.iterator], and so on. Your existing dispose() method might take arguments, or it might return a promise, or maybe you have a field called dispose that isn't a dispose() method at all. This approach is slightly less pretty, but it preserves backwards-compatibility and avoids conflicts with the many weird, decades-old JS libraries still floating around on the web.
(Also see Array#flat(), which had to be called that because some ancient libraries modified the Array prototype to add a #flatten() method... It's a mess out there.)