I think there's a useful discussion to be had about the reasoning behind things like this. This is definitely going to be a bit of a devil's advocate thing but it brings up a much needed discussion.
One of the often cited reasons for limiting third party access to firmware and repair is that unauthorized repair could potentially compromise the safety, security or reliability of the device (or at least void the certification), and the manufacturer would still have its brand on the product and the user would not blame the third party if something broke, but rather the manufacturer. This was supposedly behind the reasons why Tesla doesn't like repair, because they really didn't want news about battery fires.
Obviously, in this particular case the safety characteristics of the original product, as you note, are terrible to begin with, so any competent third party is more likely to increase the safety than not.
But say, for example, that the OneWheel was designed with a proper engineering process. Say, for example, the ESC and powertrain was held to ASIL-D standards and the battery pack was UL 2271 [the standard for light electric vehicles batteries] certified - both are entirely reasonable standards to expect this equipment to be certified to (ASIL-D is a common standard for things like Power Steering modules in cars, which have to be robust because any failure could result in full lock to lock torque overpowering the driver at highway speed - also a system involving servo control and brushless motors.)
Such a system would involve a very significant design and verification effort to catch edge cases. Things like your wires breaking scenario would need to be analyzed as part of the design - can the design fail in a safe way when certain failures are encountered, up to and including redundancy. Things like waterproofing, as you mention, need to be tested to IP rating standards - probably at the very least IP66 for the whole device given where people use these devices.
> swapped out IMU because of chip shortage and didn't validate high pass filters properly
This wouldn't have been allowed in a certified product. When you change materials or components in a certified product, you have to redo the validation and certification process. Otherwise the certification is worthless.
*Now, given these conditions, would allowing third parties to easily replace components with random ones potentially compromise safety?*
> removing the discharge path on the BMS (so it couldn't power off the board unexpectedly)
This one, for example, IMO, is questionable. I would argue that it does reduce safety, and given the original DRM, this is what they are trying to prevent. Clearly, some level of certification was achieved for the original battery pack (UN38.3, mandatory to transport), and they don't want this modification to happen.
Given the rising dangers of battery fires and explosions, I believe that BMS system integrity has never been more important, as these devices have a MUCH greater risk exposure (24/7 potentially) and to a much greater population (anyone living in a building with at least one of these devices in it). Even big players like the Tesla Megapack have fire problems, and that's with a proper safety management design. Let's say, for example, a MLCC on your ESC fails, cascading into an arc fault involving the PCB, carbonizing and fusing the copper layers together (there are examples of this happening on even lower power designs). Without a discharge path, the battery and the device will now need to convert 1 kWh of power into heat over about 5 minutes. This is going to set the carpet on fire.
Under UL 2271, and actually under all of the UL standards for batteries if I remember correctly, you need to pass all of the safety tests for the battery with one set of safety devices not otherwise certified (i.e. mosfets as opposed to UL rated battery fuses) "faulted", which means that commercial batteries like the Segway Ninebot scooter batteries are usually fitted with multiple layers of MOSFETs and cell protection ICs. Of course in this particular situation, you don't want the battery to cut off too quickly. And thus, this would call for specific and deliberate engineering to design a solution that will protect against both sudden failure and fire.
Looking to the broader system, the VESC system proposed as a replacement for the original controller is likely more robust in actual usage, but I don't personally think it's a direct alternative to a properly designed first party solution. VESC hardware is largely a DIY-grade prototype hardware and software, which, while functional, I don't consider (and they explicitly claim) is not safety critical. I kind of did wish for a while that they would actually attempt to build such a system, because it would have been nice to have an open source solution with a safety-grade lockstep microcontroller, redundant power paths and whatnot, etc, but after spending some time in that community it seems that the thrill of danger is part of their idea of fun, so I'm not holding my breath waiting.
This brings me to I suppose what my actual point is.
I think that in some cases, software locks that attempt to prevent the unsafe modification of certified and safety critical systems are acceptable. I think that instead of disabling functionality, the app should just pop up a warning that the system has been modified. This is what Google does with bootloader unlocking and what Apple does with their "important display/battery/camera message" notifications, or what Samsung does with Knox. I'm not opposed to these types of schemes because the lifespan of a $2000+ device is likely to be very long, and it's important for downstream users to be aware of the modifications that have been done, and for the manufacturer to be able to say "hey, this is modified, the certification is void, it's your problem now" when it inevitably turns into an accident.
I do, on the other hand, believe that it is valuable to allow users to prototype and develop on hardware they own. This is why I propose that the software locks do not disable functionality entirely. I also think that by replacing all, or a significant amount of the internal components of your device, it is no longer a OneWheel, it is your own creation, and as such, the manufacturer should not, and (tbh already cannot) restrict what you do with it. I'm okay with the manufacturer requiring that its trademarks and the certification marks be removed as well.
I think that a robust framework where manufacturers can prove that they are doing what is necessary to make these devices safe is extremely important especially as this is an emerging market. We are already seeing anti-PEV regulation in various markets, with these devices being technically illegal where I'm from, and NYC banning some PEV batteries (?). If these transportation devices are to become popular and accepted and eventually legalized, something has to be done, both from the DIY side (to promote actual and demonstrable safety) and from the manufacturer side (to certify their products and deliver products with a track record of safety). Otherwise, I think eventually the burden on these devices will eventually push them out of the market.
