… how about dealing with the issue at the user level?
Basically, if you don't like the proliferation of boards, there are two ways you can handle it:
1. Learn about computers and write code that aggregates the board topics you want the way you like for yourself.
2. Request a "composition" capability from the Lord High Edecutioner.
There are two general approaches to composition:
A. Allow users to create their own custom boards that link any selected boards together.
B. Allow users to pairwise link one board with another with inheritance.
I would recommend 2B, with directional inheritance. (If I link a->b then b->c, a shows up in c because it is already showing up in b; but if I link b->a and b->c a doesn't show up in c because a isn't linked into b.)
Actually, I recommend 1, but don't think that would happen.
2A could easily become a dead data nightmare for the site, unless you limited both quantity (number of composed boards), size (number of boards composed), and currency (how long you keep a composition without reading it). Even with those limitations, which would spark endless complaints, checking for infinite recursion in the supersets is a time-consuming proposition.
2B is a little harder for the user to manage (than 2A, but far less work than 1), but is cleaner, uses fewer computer resources for TMP, easier to automatically police with code, and would run faster.
It is also multiply reentrant. A user can create a tree like:
a->b
b->c
d->e
c->f
e->f
and get the following options:
read a, get a
read b, get ab
read c, get bc
read d, get d
read e, get de
read f, get abcdef
So … 1, 2A, 2B, none, or what?