FWIW: the failing tests here are present on master and probably every other branch too (covering whatever might be right or wrong about my implementation here). They look like this, if this is the first time you hear of them:

> ./node_modules/.bin/gulp runtests
[08:28:36] Using gulpfile ~/vc/TypeScript/gulpfile.js
[08:28:36] Starting 'runtests'...
[08:28:36] Starting 'generateLibs'...
[08:28:36] Starting 'buildScripts'...
[08:28:36] Finished 'generateLibs' after 194 ms
[08:28:37] Finished 'buildScripts' after 369 ms
[08:28:37] Starting 'generateDiagnostics'...
[08:28:37] Finished 'generateDiagnostics' after 579 μs
[08:28:37] Starting 'buildShims'...
[08:28:37] Starting 'buildDebugTools'...
[08:28:37] Finished 'buildShims' after 303 ms
[08:28:37] Finished 'buildDebugTools' after 303 ms
[08:28:37] Starting 'buildTsc'...
[08:28:37] Starting 'buildTests'...
[08:28:37] Starting 'buildTypescriptServicesOut'...
[08:28:37] Starting 'buildServerLibraryOut'...
src/harness/vfsUtil.ts:666:47 - error TS2345: Argument of type 'string' is not assignable to parameter of type '"ascii" | "utf8" | "utf-8" | "utf16le" | "ucs2" | "ucs-2" | "base64" | "latin1" | "binary" | "hex" | undefined'.

666             return encoding ? buffer.toString(encoding) : buffer;
                                                  ~~~~~~~~


Found 1 error.

[08:28:40] 'buildTsc' errored after 3.1 s
[08:28:40] Error: Process exited with code: 1
    at ChildProcess.<anonymous> (/Users/jhs/vc/TypeScript/scripts/build/utils.js:54:28)
    at ChildProcess.emit (events.js:311:20)
    at ChildProcess.EventEmitter.emit (domain.js:505:15)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12)
[08:28:40] 'runtests' errored after 3.84 s
[08:28:40] The following tasks did not complete: buildTests, <series>, <series>, buildTypescriptServicesOut, buildServerLibraryOut
[08:28:40] Did you forget to signal async completion?

Ah, that was addressed by @Kingwl in #38525 – thank you! Rebased this PR on top of that fix.

@sandersn, are you taking the opportunity with the 4.0 major release to land PRs like this that stricten overly-loose types?

For this PR, I'm waiting for the originating issue #35865 to be discussed and accepted. That happens during regular backlog triage meetings, and is sometimes followed by a design meeting discussion with the whole team.

In general, Typescript doesn't follow semver for a couple of reasons. The first is historical -- we started with the old-school point-release version numbers on a regular release schedule. The second is that is our product is all interface -- every release breaks things, and it's not easy to predict which things will break in a large code base, so there's little value in major-vs-minor releases.