Limits of share operator's ref-counting default in RxJS

Goal: Clarify the default multicasting behavior of RxJS operators share, shareReplay, and publish—specifically whether they should automatically ref‑count subscriptions or require an explicit connect call to control hot/cold semantics.

Constraints: Changing the default impacts existing codebases, influences subscription lifetime management, and affects the likelihood of unintended memory leaks or premature completions; any decision must balance ergonomic convenience with predictable resource usage.

Questions: What are the trade‑offs of making share‑like operators ref‑counting by default? How would altering the default affect backward compatibility for applications that rely on manual connect? Should RxJS provide a separate operator variant to opt‑in to ref‑counting instead of changing the existing defaults?