Splitting our sets into different set lists (one set list per pool) and then enabling only the relevant set list as I cycled through the desired list of MOCs for that pool was exactly how I figured out which extra parts we needed to buy (a somewhat scary list in itself!).
My resulting list of extra parts is almost certainly not minimal but it does mean that junior can choose any one `car', any one `digger' and any one `crane' from the list and we will (eventually) have the required parts in hand. Using the approach you suggest I could determine the minimal collection of extra parts necessary for any particular selection of MOCs. However, the drawback is that I would have to cycle through all combinations of any one `car', any one `digger' and any one `crane' and keep the maximum count for each different part from every one of these combinations to make sure that I had enough parts in hand to satisfy all possible requests. Allow even just three choices for each pool (`car', `digger' and `crane') and the number of combinations is painful. Add one more MOC choice to any pool and compare how hard it is to recompute what extra parts you need to obtain using each approach. I'm trading some more extra parts for much less computational complexity given my self imposed requirements.
Please don't misunderstand my intentions. I'm not trying to dismiss your approach which works and has other separate uses, I'm just trying to lay out some of the pros and cons which may well differ depending on your requirements. For all I know the poster above and I may be the only two people interested in multiple parts lists or the feature may just be too painful to implement. Thanks again!