Reimplement and generalise BridgeDB?

Over at legacy/trac#30946 (moved), I spent several hours trying to port BridgeDB to Python 3 but progress has been frustratingly slow. Given the port and our in-progress grant application proposing a social bridge distributor, I started thinking about a rewrite of BridgeDB. Here's how I see the (dis)advantages breaking down:

Disadvantages:

• Re-implementations are never as smooth and straightforward as anticipated. It will take a lot of time.
• We won't (easily) be able to use Stem to parse bridge descriptors. We could extend zoossh though.

Advantages:

• We could re-implement the service in golang because the anti-censorship team is comfortable in the language.
• We could generalise the concept of BridgeDB: What goes in should be an abstract type of proxy (be it bridge descriptors, snowflake-style proxy registrations, or maybe even Lantern proxies) and distributors (as we already have them in BridgeDB) determine who gets these proxies.
• We would design the service with redundancy and "containerisation" in mind.
• It would make it easier to add new features, especially significant ones, like a new distributor.
• A re-implementation may be a return on investment and save us time in the long run.

Note that we don't need to abandon BridgeDB and then redirect our focus to its re-implementation. I would instead like to spend some hours experimenting with a new design in parallel to maintaining BridgeDB. We also don't need to aim for a feature-complete replacement of BridgeDB. For example, we don't need to PGP-sign emails. If all of the above proves fruitful, we can gradually transition to the new design.

Thoughts? Any other features or architectural changes we should make in a re-implementation?