D is garbage collected, which rules it out for embedded systems.

They're working hard to reduce the dependency on the GC as much as possibile. I think if they had done that and the C++ interop a few years ago D would have had more success, but with limited resources I understand that it may have been to much of a burden on the language development proper.

Really?! Java doesn't have any problems with that.

http://www.ptc.com/developer-tools/perc

https://www.aicas.com/cms/en/JamaicaVM

http://www-03.ibm.com/software/products/en/real-time

The problem with D's garbage collector is that it just a very old implementation, with performance problems and they lack contributions to improve it.

Those are all running on RTOSes such as RT Linux on an X86/PPC or full ARM platform.

Those won't run on an ARM Cortex M chip, where your current options are effectively ASM, Ada, or C if you want high performance and low price and power consumption.

They also run bare metal.

Do you want commercial products specifically targeted for ARM Cortex M chip with GC enabled languages?

Bare metal Oberon compilers for ARM Cortex-M4 and Cortex-M3:

http://www.astrobe.com/default.htm

MicroEJ developed in a mix of Java and C.

http://www.microej.com/products/device-software-development/...

D does catch on slow and steady. ;)