Right now this is building on top of OpenOCD, JLink's command line tools, Bossa and Teensy Loader CLI, but in all of these cases I am considering a native Rust implementation to get additional functionality and reduce the number of dependencies; STLink, DAPLink / CMSIS-DAP, and JLink protocols are reasonably well documented at the USB level. This would be very useful for doing MCU probing, emulating command line arguments + return codes, debugging (setting data watches and breakpoints at the command line), and SWO / JLink RTT.
I'm also keeping an eye on https://github.com/mbedmicro/FlashAlgo.
I'm not interested in reimplementing all of OpenOCD, but there's a useful subset of functionality that would be nice to have - especially if we could reduce the number of non-Rust dependencies needed to start embedded development. Your work with alternative linkers is the most important piece of that, though I've experimented with adding rustup-like functionality for managing the arm-gcc toolchain installation.
I've purposely avoided looking too closely at PlatformIO so that I'm not overly influenced by their overall design, but in the last couple of weeks I've relaxed that rule a bit and I can see that there are parallels. A lot of what PlatformIO is doing is implementing a C / C++ packaging system, which Rust doesn't need since we have Cargo. They are also pulling in existing C / C++ frameworks such as MBed and Arduino which don't currently have parallels in Rust.
There is also a library of board and MCU descriptions, but I don't know the details of how they are implementing that yet. For Rust, this information should be encapsulated and published in crates where possible. The challenging part is making it so that board and MCU crates can share common implementations and drivers down to the peripheral level.
libopencm3 has done some of this, but in a fairly limited fashion using lots of C preprocessor functionality.