I know I’m repeating myself, but these thoughts get buried in posts.
A common systems design technique is called publish/subscribe (or was 25 years ago... I’m sure there are acronyms for it now). It allows for independence of different modules and parallel processing... which are wonderful things. Using this design approach, the main startup task could publish message “we’re starting up! Lemme know when your done!”, and 30 subsystems that control different aspects of the car could, in parallel and more or less independently, go through their wake up process and then report “done!”
Problem is, if there are sequence dependencies, like the USB driver really needs to be running before the media player does its startup, you get issues if the tasks finish out of order.
Given this USB issue as well as a number of other intermittent startup issues I’ve seen (sometimes not displaying backup camera in reverse first time, no PRND indicator on screen, and a few more)... I strongly suspect that this architecture was used widely in the Tesla software. IF that is the case, what seems to us a super simple bug that they just won’t spend a day to fix might in fact require a very intricate diagnostic, redesign, recoding, retesting effort that they don’t want to do.
One software guy’s guess. I don’t think they are just being spiteful to music lovers. But maybe I’m wrong.