We are currently jumping through a lot of hoops in order to preserve the type through the operator chain, when that is no longer as relevant. As a hold-over from the dot-chained days, there was an attempt, starting in v5, to maintain the same type through operators by leveraging lift. This was done such that this would still work:

class CustomObservable<T> extends Observable<T> {
  specialMethod(): void { }
}

const custom = new CustomObservable<T>;

custom.filter(fn).map(fn2).mergeMap(fn3).specialMethod()

Over the years this has proven to have limited value, and in fact, is flawed in some ways. For example, look at the code we've had for years in order to support "lifting" publish operators in such a way that connect composes through.

Fact is, the current implementation doesn't support what it claims, because if you have more than one publish operator in the chain, it breaks connect. Try this:

This doesn't work:

interval(100).pipe(
  publish(),
  publish(),
  refCount()
).subscribe(x => console.log(x));

And this doesn't work:

const source = interval(100).pipe(publish(), publish());
source.subscribe(x => console.log(x));
source.connect();

This the byproduct of a few things, but chief among them are:

1. publish() et al, should not be "pipeable operators".
2. Composing custom types (or even Subject) through the operators via lift was a cool experiment, but ultimately was of limited value and required some strange workarounds in all cases.
3. Implementing lift on a subclass of Observable requires the developer to have knowledge of Observable's implementation details. (You have to set subclass.operator and subclass.source etc).

For version 8, I'd like to eliminate the composition of types like ConnectableObservable, Subject and "custom observables" through operators as a goal.