Yeah, speed up the MCU, add a resource-eating OS and make yet another new Pi.
The USP of Teensy is it's bare metal simplicity at maximum usable power. Once an OS is in, there are others already well ahead. It would be like turning around to chase the ones who went the other direction years ago. BUT WHY?
Because, at the end, it's EASIER to use. Your PC can do multitheading, too. Ever thought about the "why"?
Up to Teensy 3.6 I said the same. We don't need multithreading there.
But the T4 speed changes everything... it spends the most of the time either waiting or running through "loop()" senseless fast. But while it waits, it can do other, more useful things.
Yes, yield() is intended for this, but is very unflexible.
But you're right - perhaps it makes sense to add a switch that enables/disables multithreading(?)
@Paul: I'd begin even more basic.. with a useful stacktrace when something crashes. First, for the hardfaults, then, maybe we can try to remove -fnoexceptions?
This will make debugging much easier. The next could be wire, and adding a mechanism for timeouts/watchdogs and semaphores.. later mailboxes.. all things that we will need sooner or later. we can test these with wire
@Deleted User: wouldn't it be useful if the slow I2C could run "in the background", for several devices, without thinking too much about it? And at the same time doing fast USB and SPI in parallel? We will have a 2nd core for this...
If you use Audio or USB you already use multithreading. Its just called different. Interrupt. For Audio: Software-Interrupt.