At least my personal perspective is that the spec allowing all these types of different cables with the same physical connector and no way to tell how they will behave is the problem.
This really is different than the “monster hdmi cable” vs “best buy brand HDMI cable” from 15 years ago.
This is one of those cases that the more expensive type C cable will be higher quality and be able to handle more optional things from the spec.
Unless you’re buying from Amazon, where hundreds of fake reviews can be easily bought and the cables could be $50 but still shit
USB-C is the most frustratingly awful connection “standard” to troubleshoot because every cable and every port have a (mostly) undocumented compatibility set and (usually) have a boat load of technical and design quirks to deal with. “One connector to rule them all” is both a great marketing slogan and a terrible way to actually design connections. 
Totally agree with you here. And I’m happy that I fiddle with linux since end 1992, because I know my way around Linux, and logs, and kernel ring buffer and stuff, and can see pretty fast if the cable works as expected.
But my test was pretty simple. I have one external NVMe enclosure that came with 2 cables: USB-C to USB-C, and USB-C to USB-A. These cables work with all my devices and showed absolutely no error in the kernel ring buffer.
I then took all the other cables, and checked the kernel ring buffer when I plugged them into 4 devices I have at home for testing: Raspberry PI 4, DVD Drive, Camera and SSD NVme and SSD S-ATA connector.
If that showed only 1 error in the kernel ring buffer while plugging in, I dumped it.
I used a similar approach testing the iPhone 15 issue. I have a verified and tested Samsung branded cable from a recent monitor purchase that I always use for connecting the iPhone to my desktop. When I was testing the Framework USB issue, I would test the laptop and then use the testing cable on the desktop to download any pictures that support wanted.
Final update on the issue for now: After 5 days of troubleshooting, Framework Support finally admitted that there is a known issue connecting iPhone 15s to Framework 16 laptops and that they are actively working on a solution. They do not have an exact date on a fix yet. Any further issues will be communicated via the Framework Community Forums. They also recommended not plugging in the iPhone 15 to the Framework to avoid any further issues. My opinion: It is not a great customer service experience to get a “this is a known issue - please stand by and don’t use it for now” response after 5 days of intensive research and troubleshooting.
I don’t see it anywhere in the posts here, but for those unaware - it seems they promoted the BIOS and driver bundle out of beta. Linked here Framework Laptop 16 BIOS and Driver Releases
I’m confused. You are only looking at the “kernel ring buffer”, so the part that logs before the system fully starts up and standard log tools take over…are you only testing all these on boot-up or something? Can you clarify your methodology?
The Kernel ring buffer stores all events having something to do with system/hardware/driver interaction. Not only at boot, bot afterwards too…
Either in a console you can look at it with sudo dmesg -Tw or sudo journalctl -b -f, then plug/unplug the cable.
If the cable is detected, check for any error message that shows up and google their meaning.
Ahh ok, gotcha. In my linux circles we never refer to it like that, we just say “dmesg”. I guess it goes with the linux idea of finding the shortest command/word possible to convey meaning.
Thing is - what’s in the kernel ring buffer can be called even during a kernel panic → Magic SysRq key - Wikipedia 
This helps a lot to troubleshoot the cause of a crash/hang. And on the console, you always get an result with that.
Is there good reason to update firmware that’s still in BETA? I feel more comfortable waiting for it to be out of beta and not adding the lvfs-testing remote. Is that fine to wait for, or is this an important update to get sooner than later? I don’t really understand firmware enough yet to make an educated decision.
My understanding is that since it was published to the official bios updates page, the update is no longer in beta.
running fwupdmgr get-updates though doesn’t yield a bios update, so either it’s still in beta, or the “release” version is still only in the lvfs-testing branch, which I’d still prefer to avoid
It may need some time before it finally lands in the stable lvfs channel. For the beta release they mentioned:
We are waiting for metadata to rebuild in 4 hours
Only if it fixes issues that bother you. Otherwise, you might as well wait.
I do wish there was more of a concrete, “this is no longer beta” than just Framework’s informing us of the timeline that if no probs within 2 weeks then it’s no longer beta and the stealth removal of Beta from the thread title and stealth posting on the firmware and drivers page.
So is this no longer Beta then? @Kieran_Levin
I have tested so many Alpha versions in the open source world, and they usually are way better than the official released versions from a certain other big player.
Beta does not mean “not finished”. It means that they made fixes and it is in testing phase.
Usually when no new errors appear, that Beta becomes the finished “release” version.
But as others already said. If you have no issues, don’t apply/use it. Period. Your choice.
Keeping one or more “charge only” cables can be good, ensuring safety when charging from unknown USB plugs. I’ve heard stories of Laptops being compromised from USB ports while supposedly just charging.
I have had issues connecting to my iPhone 15 pro max even before the firmware update.