Because it's a large, widely-used project with relatively few core developers. Many other projects have similar numbers of issues, that's not unique to MicroPython! For example, I admire Zephyr's organisation, yet they have double the issues and 5x the PRs.

> They need to test the whole ecosystem...and for every bug fixed there should be a unit test...

Sure, that's a great ideal to strive for. That was - and is - the case for the language and interpreter. It's becoming more common for port-specific code as the tools to allow automated hardware testing are implemented. But it doesn't happen overnight and it's a large surface area.

> I had this conversation with them but they take every opportunity to justify/ask for more funding.

Ah, I presume you're referring to this discussion?

https://github.com/orgs/micropython/discussions/13436

No-one asked for funding. Some noted that such testing infrastructure doesn't come without effort or for free.

BTW I'm not sure if that was you, but that post had a pretty unhelpful, disrespectful tone. If that was you, I suggest you check your tone and get in and help create some tests. We'd appreciate the help!

> They are also prioritizing adding support for new chips...

That's often paid work. Recent paid work has helped fund HIL testing. Further, a careful expansion of the number of ports is necessary to avoid becoming irrelevant.

> ...get eaten alive by chaos, regressions and platform fragmentation

I use MicroPython commercially, daily...and I don't share your experience with chaos or regressions. Sure, sometimes issues occur, particularly if you're on the bleeding edge - but they're pretty well controlled and rapidly fixed. YMMV.

As for platform fragmentation, I struggle to understand your concerns; it has been improving for a long time now as developers have focused on ensuring compatibility between ports. Again, yes, there are some differences - but given how radically different the micros can behave, the consistency between ports is pretty remarkable.