Is this limit of four bridges tied to some other capability?
Yes and no.
I've taken a brief look at some .h files on K24 sources and it seems to use an integer as a 'unique identifier' for network interfaces (see struct net_device on src/linux/linux/include/linux/netdevice.h). Since we're talking about a signed 32 bit integer, this means it should be possible for the Linux kernel to handle a lot of network interfaces - that is, in theory. Therefore, we should only limited by the amount of memory available on our systems at runtime - that is, as far as I know…
In any case - there might be some other things to be considered:
- most of the routers/devices out there have very few/limited resources available
- most of these devices are targeted for home networks and/or small businesses
- most of the code for these thingies has been carefully written/crafted so it can run even on my 'ancient' WRT54GL
- most of the devices out there have just 4 ethernet ports available for LAN (+WAN)
- a lot of code in Tomato has been written assuming there would be only one LAN bridge at runtime (which would require some extra coding/patching/etc… to support extra/additional LAN interfaces)
With that in mind, it sorta made sense to pick a nice/round number such as… 4 ;)
To make things a bit more complex/worse, while digging into the Tomato sources I eventually got to src/include/bcmparams.h, which defines DEV_NUMIFS as 16 (Max. # of devices/interfaces supported). While this particular value/limit has been raised to 32 on my most recent code (to be pushed to git soon), I'm not entirely/positively/absolutely sure if such change will be actually 'safe' (i.e. not sure if this is the 'only' piece of code that needs changing, etc…). I guess we'll just have to wait and see how it goes for others (but seems to be working fine here, according to my tests).
Any particular reason you need more than 4 LAN bridges?