The coded frame processing algorithm introduce the concept of Coded Frame Group. If the coded frame processing algorithm detects a discontinuity, a new coded frame group will be started and the need random access point flag will be set.

The coded frame processing algorithm handles multiple successive runs nicely.
The only call that could interrupt a coded frame group currently is the Reset Parser State.

The coded frame removal algorithm however takes no regard to the current coded frame group.

It is possible to call remove with a range that intersects with the current coded frame group ; which would introduce a discontinuity.
A follow up call to the coded frame processing may render the track buffer unplayable as it wouldn't have detected the introduced discontinuity.

something like:
sourcebuffer.appendBuffer(init + mediasegment[0-10));
waitfor("updateend").then(
sourcebuffer.remove(5, 10);
);
waitfor("updateend").then(
sourcebuffer.appendBuffer(mediasegment[10,20));
);

if the first frame of the last media segment doesn't start with a key frame, the trackbuffer content is now undecodable.

I suggest amending the coded frame removal, following step 4, and prior to step 5 (which would become step 6) with something like:

If the last decode timestamp for track buffer is set and if any of the coded frames removed in the previous step have a decode timestamp that equals to the last decode timestamp:
 1. Unset the last decode timestamp on all track buffers.
 2. Unset the last frame duration on all track buffers.
 3. Unset the highest end timestamp on all track buffers.
 4. Set the need random access point flag on all track buffers to true.

There may be something to do related to the group start timestamp that I haven't considered, likely need to unset it.