bufferTime and bufferCount will mutate current buffer if a source is a subject that emits in the subscription for that buffer

RxJS version:
5.5.2

Code to reproduce:
rxfiddle.net

const x = Rx.Observable.interval(1000);

const z = new Rx.Subject();
Rx.Observable.merge(x, z)
	.bufferTime(5000)
	.subscribe((value) => {
  		console.log("Before", value)
                z.next("HELLO")
  		console.log("After", value)
	});

rxfiddle.net

const x = Rx.Observable.interval(1000);

const z = new Rx.Subject();
Rx.Observable.merge(x, z)
	.bufferCount(3)
	.subscribe((value) => {
  		console.log("Before", value)
                z.next("HELLO")
  		console.log("After", value)
	});

Expected behavior:
That "HELLO" would be logged out as one of the buffered values for every console.log(value) barring the first, and the array of value would remain a constant set through each individual subscribe.

Actual behavior:
The value of "HELLO" is pushed onto the end of the current buffer array, mutating it.

Additional information:

This came up whilst attempting to use rxjs to develop simple physics simulations with a Redux-like scan/reducer. A step for that scan is to emit any follow-up events to be processed in the next 'frame', and I discovered those events were being silently thrown away by the bufferTime operator. Since discovered they aren't so 'thrown away', but 'mutated onto the current buffer'. Which isn't useful if emitting them is the last part of the next step.

Whilst there are better ways to architect the code that avoid doing a subject emit like this, which is what I did after I confirmed this was the current behaviour, this still seems like either a bug or a 'gotcha' which I could not find documented.

Start with the implementations and existing tests for the bufferTime and bufferCount operators, then reproduce the mutation with the two snippets in the issue. Done means the value emitted from the Subject does not mutate a buffer already delivered to the subscriber, with coverage for both operators.