Consider not allowing implementation-defined choice of data property or accessor

[dminor]

From @ljharb's comment #10 (comment), this allows implementations too much latitude, and we should specify either a data property or an accessor, but not both. I followed up with him, and he has a preference for accessor over data property.

[ljharb]

I also don't mind/care if it installs a data property on non-Errors, but for Errors, imo it basically must be (per precedent/consistency with the rest of the lang) be an internal slot read by a prototype accessor.

[mhofman]

FWIW, a data property is explained as the setter being immediately triggered with the value returned by the getter. What I'm interested in however is codifying that if an implementation takes either approach, it does so consistently in that realm.

That said it seems the question here is what to do for target objects which are error instances. I believe there may actually be a web compatibility question here. I do not recall if v8 uses the same accessors for captureStackTrace and for native errors, and whether the error data of an error instance is overridden by capture stack trace, or whether it's stored in another slot and the native error ends up with 2 internal "stack data". @o- can you chime in?

That said, I given the "stack setter defines a property" behavior, I am still not convinced we must prescribe installing an accessor on error instances.