I'm wondering whether it would make sense to do compiler bootstrapping to speedup further development and bugfixing?

This is inspired by a recent comment from Andrei (https://github.com/D-Programming-Language/dmd/pull/1489) ("I think we're getting closer to the point we could and should do some bootstrapping inside the compiler. Using D for tools may be a simple entry point."). This came up regarding the difficulty in doing simple things in portable way in C (eg vergen.c).

Here's how this could work relatively easily:

1) define a good enough D specs (called D_specs_frozen). We could use a dumbed-down version (D1) but might as well use specs from the latest D2.061 release, which includes UDA etc. Compile corresponding source code (D_src_frozen) to obtain dmd_frozen executable. Development on D_src_frozen stops (only very critical bugfixes, see below).

2) start a new fork of dmd (D_src_bootstrap) from latest dmd version and gradually rewrite most/all of dmd in D_specs_frozen language. This can be done incrementally, using a mix of c and d files as intermediate stage and converting them one by one (can be semi-automated). I counted "only" 181 C files, which is not excessive. Compile dmd_bootstrap executable using dmd_frozen. The D specs can continue to evolve at that point, new features get added and bugs fixed.

Note, D_src_frozen still contains bugs, but a majority of which won't have to be fixed in the D_src_frozen branch. That's because there'll be only 1 project that depends on D_src_frozen, which is  D_src_bootstrap, so bugs or language limitations can be dealt with for that one project. Any other project will be based on the continuously improving new D branch.
Instead, people can focus on fixing bugs and enhancing features in the D_src_bootstrap branch, which should be orders of magnitude easier given that it'll be written in D D_specs_frozen instead of C++.