Agreed. I have done this already (I reported it as two bugs, one summarized as "USB playback of my relatively large (25k track) library fails with media player hang or restart" and the other as "Media player UI is unusable for non-trivial libraries because no non-sequential access is provided"). I did get a reply that included "please let us know if you do not hear from service within a few weeks on this", I have a nag set up in my calendar for two weeks from now.
There are certainly other bugs, but for me, those two were the elephants in the room. If they had a good user-accessible bug reporting system, I'd open a bunch more at lower priority, but as it is I didn't want to distract them with less-important stuff.
FWIW this is an excellent -- and brief! -- guide on how to write a helpful bug report. Obviously, we're not reporting bugs against emacs, but the principles remain the same. GNU Emacs Manual: Understanding Bug Reporting
Edited to add: I sent my report to [email protected]
As someone who has to respond to bug reports (not for Tesla), it's always most efficient when the bug report gives details on how to reproduce the problem. If a problem can be reproduced it can usually be fixed quickly. Clear, concise bug reporting is a bit of an art, but most people can learn the method.
I'm also a software developer. One of the big things with developing software, particularly if it's for a commercial market, is controlling regressions. Sure software is hard, but if you let your development get out of control, it becomes VERY hard. That's what Tesla has done repeatedly. They seem embody the classic joke of letting their software escape rather than be released.
IMHO the best way they could fix this is by opening up a sandboxed API so that competent people could fix the software. Failing that, someone in authority at Tesla needs to take a big broom to their software department.
I have a friend who is a software project manager and her specialty is turning around dysfunctional teams. She told me she's been asked to look over a lot of software over the years. She said when the interface looks perfect, her first though it "uh oh!" because it's rare to find someone who is both a good interface designer and good at the internals.
Designing good interfaces takes a different way of thinking than it does to get the internals working. Ideally they should be two different people.
And even if you're decent at designing an interface (or software), once in the hands of users somebody is guaranteed to do something you never thought of. I had a Murphy's Law poster many years ago and one of them was "Whenever you try to make something foolproof, the universe will invent a better fool." Not that end users are all fools, but if you design software to work a certain way, they will do it differently and mess everything up unless you build in that contingency or lock out that possibility. The Windows and Linux world tends to favor multiple ways to get there. The Apple world tends to lock out other possibilities and if their way doesn't make sense to you as a user: too bad.