FIRST OF ALL, I just LOVE this repo, my whole day was just me trying to find a proper polyfill that actually works, lots of them just die.

there's one bug which is because of Object.assign(this[sRespHeaders], resp.headers);
resp.headers is actually not a Record<string, string> more like an iterrable/entries
to fix it just Object.assign(this[sRespHeaders], Object.fromEntries(resp.headers));

another suggestion, you could use the private identifiers feature

Hi! Thanks for making this. You should add a license if you intend for others to make use of your npm package. An easy resource is Choose A License.

Thanks again!

I have seen this pattern from times to times

  [sDispatch](evt) {
    const attr = `on${evt.type}`;
    if (typeof this[attr] === "function") {
      this.addEventListener(evt.type, this[attr].bind(this), {
        once: true
      });
    }
    this.dispatchEvent(evt);
  }

but the one i have encounter is more like this

  dispatchEvent(evt) {
    this[`on${evt.type}`]?.(evt)
    super.dispatchEvent(evt)
  }

but on properties should really be a getter and a setter
cuz if you set a properties to anything other than a function, then it should be set to null

so i think this way is better:

class XHR {
  #onload = null
  
  set onload(fn) {
    // always remove the prev/cached listener for when it gets deleted or overwritten
    this.removeEventListener('load', this.#onload) // works ok even if value is null

    if (typeof fn === 'function') {
      this.addEventListener('load', this.#onload = fn)
    } else {
      this.#onload = null
    }
  }

  get onload() {
    return this.#onload // should always return null if not a function
  }
}

Then you don't need to override the dispatchEvent which really should be the same as if you where to compare them
XMLHttpRequest.prototype.dispatchEvent === EventTarget.prototype.dispatchEvent

yea, it can be more verbose, but it dose more follow the way of how on properties should work if you where to do something like xhr.onload = 0; xhr.onload === null

there can be way to optimze this pattern for multiple on properties on the same class

Why not just recommend to switch to using the fetch api instead?