I initially thought I could simply use a stable OpenWrt and point its feeds.conf to to packages' master branch and start building image, but then I found commit like this that requires changes in the OpenWrt itself, which obviously isn't available in stable.
I wonder if using bleeding edge packages with stable OpenWrt is officially supported or I should use OpenWrt snapshot instead if I need some packages from the master branch?
It is not supported (at all), there is no binary compatibility between different versions of OpenWrt, nor sufficient versioning (SONAMEs, API- and ABI tracking, symbol versioning, concurrent libraries) in the first place.
The only way you may approach this, is on the source (-package) level - and only with a careful eye on what needs changing within a different environment.
Sorry, my wording was probably unclear, I've updated title.
I'm not looking for binary compatibility. I'm building OpenWrt from the source, but I'm trying to build OpenWrt stable source with packages in the master branch. Given commits I mentioned that requires updated OpenWrt, I wonder if it's achievable?
Well, pretty much the same applies - there is no intention to keep the (master-) package feed compatible with older releases. Changes and package updates are only updated on an individual basis, as (deemed-) needed or otherwise beneficiary. Support for no longer required environments (e.g. older toolchains) is both actively removed (to lessen the maze of package interdependencies and Makefile magic) and passively, simply by ongoing maintenance or updates. Feeds only need to work within their respective versioned branches.
So am I correct that building (master-) packages with stable OpenWrt is a hit-and-miss, that if a package hasn't been touched by a commit that requires an update OpenWrt, it might build successfully, but it does, it can fail?
Is running master OpenWrt in a home router a bad idea?
Depends on your level of involvement (to which extent you want to track master, as wanted updates trickle in - or to follow up with potentially introduced bugs), I've been doing so for over a decade (building from source/ master, every ~2-8 weeks, depending on what's been merged or about to be merged) - hasn't treated me badly so far. In all those years and over two dozen of different devices (spanning 10 target architectures so far), I had to resort to serial console (bootloader based-) recovery twice - on devices without 'sane(r)' means of recovery.
If you want to be on the safe side, restrict yourself to devices that come with mature recovery means (push-button tftp recovery, webif based recovery, serial console easily accessible, etc.) - and have some kind of backup plan (cold standby) at hand.