Its /a little/ more complex than that. The RFC does /not/ call for closing down a BGP session when you change your route filters. Cisco's have to do this, but its not part of the RFC. So, if I, for the sake of argument, added a new filter /after/ I made an announcement to someone I would have to somewhere keep track of the fact that I made the announcement. It seems to me that this could get to be a bit memory intensive (keeping track of the state of every announcement made to every peer).
You need one bit per peer per path and code that is smart enough to use a bit map. For 40,000 paths and 128 BGP peers, thats an additional 640KB. In a 64 MB router thats 1% of memory. The reconfig code needs to be smart enough to deal with adding the 33rd peer if you want to do dynamic allocation. Gated and (unreleased) Bay code provide existance proof that can be done. When policy is changed such that something like a MED is changed, you need to go around clearing bits to indicate that the route needs to be readvertised. If the route needs to be withdrawn, leave the "I announced it" bits set. If it needs to be added, leave the bits clear. If it is changed, clear any bits to make it look like it wasn't advertised. Keep a list of routes that need attention and advertise out those that need to be advertised and withdraw those that need to be withdrawn, using the bit map to keep track of who still needs to get an update. Curtis