On workload and stuff...

the idea we had at the 2010 Potsdam meeting where we had primary and secondary developers for each product.

There is Tor core (ported to various platforms). This is code and docs. This is what matters. It is not config or packaging. Above and beyond that, if there is a demand for it, why not introduce a secondary level of suitably trusted enthusiasts to develop and manage all the various modes of operation. Officially disclaim it appropriately as an unofficial vaporware framework, wikify it, put a couple public developer packaging boxes online and see what happens. Also, you could easily publish just a set of torrc's tailored to various purposes. Or even create an online config generator with various feature checkboxes. Also, a visible and similarly adjunct FAQ and docs team for those of us who ask silly questions like myself :) And I guess, a searchable and downloadable email archive. It could save some time of some of the people who reply to 'Subject: Please help' people. TBB... Tor Browser Bundle... sure, this is useful. But a pain for each platform. I would punt it to the secondary team. Then focus on one, Torify everything, bootable Unix platform.

1. If a user wants to run both a tor-client and > tor-(relay|exit-relay|bridge) on the same host, we run into port

Goes to config generator or posted configs. Plus to some degree you get config modernization out there in Torland for free.

3. The conversion from legacy to new packaging could be a mess.

I've never had a problem being forced to accept breakage of backward compatibility. Then again, I'm not Joe user. Still, assuming there is constant new user influx, such breakage won't lead to lost capacity. That's what major.minor.rev revision numbering is for.

5. The *BSD ports system ... for non-exit, exit, and bridge relay.

Really? Users who can deal with ports can certainly deal with a little Tor config.

Conclusion

I've no objection to flag days that result in good long term gains.