hbos@, can you take a look?

Your code does not work in Unified Plan because it is using offerToReceive incorrectly.
Code snippet:

async function addVideo() {
  // Request a new stream and add it to pc1
  // then have pc2 generate an offer
  try {
	const stream = await navigator.mediaDevices.getUserMedia({audio: true, video: true});
	console.log('Received local stream');
	
	stream.getTracks().forEach(track => pc1.addTrack(track, stream));
    console.log('Added local stream to pc1');

    try {
      console.log('pc2 createOffer start');
      const offer = await pc2.createOffer(offerOptions);
      await onCreateOfferSuccess(offer);
    } catch (e) {
      onCreateSessionDescriptionError(e);
    }
	
  } catch (e) {
	alert(`getUserMedia() error: ${e.name}`);
  }
}

In Unified Plan, each track has its own transceiver which has its own m= section. So if you're adding a new track to pc1 either pc1 has to be the one creating the offer telling pc2 to create another transceiver to receive the track - here it is pc2 that is creating the offer - or pc2 has to have spare transceivers that it can reuse to receive pc1's newly added track. The side creating an answer is NOT ALLOWED to add new m= sections.

So, why does this work in Plan B? It works because offerToReceive options creates the m=audio and m=video sections, and because in Plan B you don't need multiple m= sections for multiple tracks of the same kind. A Plan B client that is ready to receive is ready to receive any number of tracks.

In Unified Plan, offerToReceive is a legacy configuration extension http://w3c.github.io/webrtc-pc/#legacy-configuration-extensions. The language is a bit hard to parse, but basically it adds a "recvonly"-transceiver for you if you don't already have a "sendrecv" or "recvonly" transceiver. Because you already have one (due to the initial call), createOffer() does not offer to receive anything other than what it is already receiving, and pc2 does not get offered anything that it can send its track to.

Try this before you create the offer:
  pc2.addTransceiver('audio');
  pc2.addTransceiver('video');
Or make pc1 the offerer.

Note that there is a bug that means you can't tell from JavaScript if a transceiver was created by createOffer() or not until further negotiation steps - https://crbug.com/911090 - but that does not affect whether or not this demo page works.

So in terms of not being able to do what "addVideo()" is trying to do above, that is working as intended and this is not a Chrome bug. If we would like offerToReceive to be more useful that would be a spec issue (https://github.com/w3c/webrtc-pc/issues) but I suggest not relying on legacy configuration extensions.

I'm marking this as WontFix (= works as intended), but feel free to correct me if #2 is wrong if this should be reopened.

Typo: It's supposed to say "pc1 does not get offered anything that it can send its tracks to" above not pc2.

Thanks for taking the time to write that out. I have a better understanding on whats going on now. The website I need to update for the Unified Plan solves signal glare by giving one of the two clients the role of generating offers for negotiation. It's always the same client that generates the offer. It sounds like one way to fix my problem is to re-work the signal glare code so that each client has the chance to create an offer when tracks are added/removed from their peerconnection, without re-introducing the glare problem...somehow. I'll have to figure that one out.

You would know better than me if this is a spec issue. Thanks again!