UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Steps to reproduce the problem:
Run the following code in Chrome, Firefox, and Safari:

    (() => {
      const ac = new (typeof AudioContext !== 'undefined'
        ? AudioContext
        : webkitAudioContext)();
      const { stream } = ac.createMediaStreamDestination();
      const [track] = stream.getTracks();
      const pc = new RTCPeerConnection({ sdpSemantics: 'unified-plan' });
      const sender = pc.addTrack(track, stream);
      console.log(pc.getSenders().includes(sender));
      pc.removeTrack(sender);
      console.log(pc.getSenders().includes(sender));
      try {
        pc.removeTrack(sender);
      } catch (error) {
        throw error;
      } finally {
        pc.close();
        ac.close();
      }
    })();

What is the expected behavior?
Firefox and Safari:

> true
> true

What went wrong?
Chrome:

> true
> false
> Uncaught DOMException: Failed to execute 'removeTrack' on 'RTCPeerConnection': The sender was not created by this peer connection.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 67.0.3396.99  Channel: stable
OS Version: OS X 10.12.6
Flash Version: 

Based on my reading of https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-removetrack, I think the second call to removeTrack should not throw, since the sender was in fact created by connection.

> ...
> 4. If sender was not created by connection, throw an InvalidAccessError.
> 5. Let senders be the result of executing the CollectSenders algorithm.
> 6. If sender is not in senders (which indicates that it was removed due to setting an RTCSessionDescription of type "rollback"), then abort these steps.
> ...