@phil-d-wilson, thank you for letting me know about the v3.0 branch 
Using pulseaudio seems like a natural choice for this project, and I’m glad you’ve made progress on this! I also read ARCHITECTURE.md and I’m impressed by the design. Well done!
For anyone else encountering this thread in the future, I’ll note here exactly what firmware changes I would like to perform, and which I’m planning to perform upon each container, using this /lib/firmware mount advise.
Bluetooth
I’d like to test an expirmental solution for the notorious bluetooth jitters Raspberry Pi 3 issues, by using this fix, by the Arch Wiki for ARM. Naturally, I plan to do this firmware change on the bluetooth container only.
Pulseaudio / Sound devices
In the v3.0 branch, there’s only 1 container that actually accesses the sound devices, and this device will run the amixer commands I need. Additionally, this container needs some more firmware files for my hardware. So these firmware files will be installed on this container only.
To summarize, what made no sense to me in the previous design, was that many containers should need the same firmware related changes to be run, and making them all perform the same actions feels wrong. Only the v3.0 design allows one to not duplicate the firmware changes code, at least it should - I haven’t done all I wrote.