Right out of the gate I'm going to say adding serial to the SAO connector is pointless, I'm sorry. I'm not sure what you'd be putting on an SAO that would require serial data that couldn't use i2c instead. Serial does not work well with hot-plugging, is not compatible with a multi-device bus situation which SAO is on multiple badges already, it's all-around a pretty useless addition, imo.

There were about 3 SAOs this year out of probably 30+ that actually made use of i2c. Even less would use serial because you'd need something beefy enough to actually /talk/ serial.. on an SAO that is supposed to be no bigger than 50x50mm. with a small power budget. And you'd have to coordinate with the badge makers or come up with some /other/ text standard on top of serial to send data back and forth and have it actually do something. This is basically what i2c is already designed for.. and as a bonus it works well on a bus because it has addressing.

All of that said, look at the common use cases. The vast majority of SAO's (I would know, I made 4) were just blinky lights and were just using the power rail. Myself and others would have loved to tap into the WS2812 data bus and extend what the badge was already doing. This would take up a single pin of a new connector. To complicate things though, some badges are now using APA102 "dotstar" LEDs, such as @borgel's firefly, and these use a 2-wire SPI bus instead. this brings us up to 3 new pins we need to make room for to support everyone. I'm not sure what the 'right' solution is here, but something involving the LEDs makes much more sense to me than serial.

Lastly, the name SAO++ doesn't leave much room for future improvements. Benchoff has been calling it SAO 2.0 or v2 for the moment.

My 2 cents. :P

One problem with i2c for the DRM-114 is that the slave has no way to asynchronously notify the host. People have worked around that by using GPIO lines to send interrupt and alarm signals back to the host, but that's adding another pin, of course.

Just about nobody used i2c because it requires a great deal of coordination between the badge and SAO. Async serial would be far easier. If nothing else, a badge that can add as a dumb terminal could be used with any number of SAOs that can provide their own serial UI.

As for the argument about needing "something beefy enough to talk serial," I humbly suggest you look at this project, does exactly that in just under a square inch drawing only a few dozen mA at 3.3v.

I understand that w/r/t the project you'd like to create, but consider what SAO was made for - essentially, to make it easy for people to get into board design and be able to say they made something without having to worry about an entire power supply and/or lipo-charging circuit. I can attest that as a beginner it's an incredibly empowering stepping stone to be able to create something that works without too much effort, designed around fun, to get you comfortable with the tools and motivate you to do more advanced work. For beginners though, adding blinkies, figuring out how to make KiCad function as an art studio while laying out a basic circuit, learning how fab houses and maybe assembly work.. that should be the focal point. On the more advanced side, you can already work with other creators to get their badge to "eat tide pods" or interact somehow with what you've made. Simple and could be added with a basic pull request.

I respect what you're designing - more of an inter-badge communication protocol taking security into account. Very much in the spirit of defcon. In my opinion though, this is adding a layer of complexity on something that already hasn't been perfected yet, even by very experienced teams - inter-badge communication. Lots comes into play at defcon, namely how to remain functional in a large crowd. Using IR isn't a bad solution for that and has only been done a couple times, but I think the idea in general is aimed at badges themselves, and would be better served as a solder-on module and/or set of schematics and standards that could be picked up and adopted by full-fledged badge creators so they have to worry less about intercommunication and could focus more on functionality. THAT is something that would benefit the community.  (Also, if a badge isn't polling i2c regularly for what's been added / removed / has a request, it's not really doing its' job, imo. Improving the standard there is something that could definitely use work and wouldn't require changing everything up.)

Meanwhile though, as I said, inter-badge communication was never the intention of SAO, and if a badge is made for such a thing, it shouldn't require an external module that could fall off in order to do so, right? I'd rather see improvements on SAO continue to help beginners with very simple needs, and tapping into what the badge is already doing LED-wise with no code required on their part except (falsely) bumping up the "NoOfLEDs" integer is about as simple as it gets :) Even so much as throwing the finickiness of serial into the mix, let alone in a bus situation where you're trying not to stomp on each other (which is an entire separate conversation) is too much for a beginner to worry about on such a simple addon.