I do wonder what the timeline is for removing the old driver from the toolchain.
The plan appears to be to maintain both the old driver written in C++ and the new one written in Swift, according to a comment from the thread I linked above.
This causes problems when the two drivers fall out of sync, for example, I was not able to compile the stdlib with the new swift driver natively on Android when I tried it last month with the Oct. 21 trunk source snapshot. The new driver complains that it cannot find the flags -disable-autolinking-runtime-compatibility-concurrency and -disable-implicit-distributed-module-import, but if I pass in --skip-early-swift-driver to use the old driver instead, it builds fine.
One reason these regressions creep in is the new swift driver is not used on the linux CI when running the compiler validation suite or building the corelibs, because there is no prebuilt Swift toolchain installed on the linux CI. It is tested on macOS however, so I'm not sure how my particular problem happens.
I advocated in the first linked thread to just ditch the old driver, which would require current platforms to build the new driver with a prebuilt Swift toolchain and future platform ports of Swift to cross-compile a bootstrap compiler.