AlainBE, thank you, PF_Productions, IAmSkipperMark, Tom, Clint, and Luis *very* much for all your help on this. Re: why it's not sorted out: I don't work for Apple, but I have extensive experience in software testing, development, and escalation support, and I can explain how the system works.
- Usually, nothing will get fixed solely by people talking about it on a forum. From a user standpoint, it feels like you've "reported" it, especially if details are given, but that will not normally result in Apple product support or engineering taking action. With some products, such as DaVinci Resolve, actual developers monitor the forums, but that is rare. There is also a valid argument it's not the best use of a developer's time.
- Posting info on a forum is useful, and the more detail, the better. In this case, several users have collectively posted enough information to broadly understand the overall problem parameters. But took a while.
- There have been numerous situations where users refuse to provide the requested info, such as an EtreCheck report or an error log. This can greatly delay problem resolution.
- For complex hardware/software issues like this case, posting information on the Apple Product Feedback site is OK but will often not produce the desired results. That site allows just 800 characters max input (including spaces) and no ability to attach files, error logs, links, etc. It is simply not designed for that purpose.
- There is an Apple Feedback Assistant app, but it requires a developer account and is generally oriented toward app developers, not end users, and not even sophisticated IT users.
- The best approach for most users is to collect as much info as possible and then contact Apple Support. If the case is escalated, this can include ongoing two-way email discussions whereby you report new findings. I believe this particular case is in that state, and IAmSkippermark is driving this (thanks!)
- If you are an experienced software developer or have done similar work, you can get an Apple Developer account and report the problem, including attachments, logs, and files needed to reproduce the issue. However, this can require lots of work if done properly. When bugs are filed this way and followed up by contacting product support, Apple has been very responsive. See attached for an example of one I filed.
However, there is a good argument that customers should not have to spend hours or days researching a bug. OTOH, those customers may spend hours or days discussing the bug on a forum, so time is being spent anyway. There is no simple solution for this, but it's important for everyone to understand what is required to get a bug fixed.
The fastest way to get a bug fixed is by achieving a specific (ideally portable) reproducible scenario and reporting it to Apple Support by opening a case. The scenario allows engineering to reproduce the problem under a debugger and quickly fix it. It also allows later testing of that scenario to ensure it stays fixed in a new software version.
But it can take lots of time and work to achieve that well-documented, portable replication scenario. When working on critical problems that I or others encountered, I've heard people say "You're doing Apple's work for them." That betrays a lack of understanding about how the system works and how serious some problems are. If not for these efforts, some problems would not be fixed in an expedited time frame, and the cost to some end users could be significant.
Errorlogs and crash logs are useful, but those by themselves may not enable fixing a bug. The underlying technical factors are too complex to explain in this post, but if anyone is interested, I can elaborate in another thread.
Incorporating even a single fix to a complex product requires a full battery of regression tests, stress tests, functional tests, performance tests, localization tests, and security tests, individually repeated on a complex matrix of platforms and configurations. If the fix involves interactions between FCP and MacOS code, it might require a MacOS update, and those have their own schedule. The fastest I've seen Apple implement an FCP fix was about three weeks from the initial report, and that was a highly urgent matter where the release contained only that one fix.
