It's not impossible or particularly difficult, but we already have 4-5 different collections of brmfmac firmware and instead of tacking another on to the build system for the Generic x86_64 image it's about time we consolidated them and came up with a sensible build-time and userspace method for supporting device/board specific nvram configs; because we currently assume devices that use the same brcmfmac chip can use the same nvrman config and that's not the case (and I suspect this is why we have accumulated multiple firmware collections over time). That work gets a little easier once we have more devices on a common Linux 4.18/4.19 kernel codebase (as the kernel-firmware repo provides the latest or common firmware, but no nvram configs) so I wasn't planning to look at it until after LE9.0. If will probably be done for LE9.2 once we start to shift some of our Android-oriented hardware groups off legacy BSP kernels, which is always a good time for package spring cleaning.
NB: in the Bluez move from hciattach to btattach the codebase is still fresh and I already found a number of cases where brcmfmac device ID's aren't mapped so devices either don't prompt for firmware or the filenames (as documented in all the howto guides you find in Google) need to be adjusted.
In summary.. if you have a homebrew solution that's working please stick with it for a while, and we'll catch you up sometime later in the year.