(EDIT: lots of time when I code I don't always work out my solution before I start codding and then when I am done I think, "wow, it would have been easier to just do this". So sometimes I have more code than needed).
That's a fairly common approach and it works ok with modding existing code. It really sucks if you make something from scratch. Also it's an approach where you really need source version control and can accept discarding your own changes because they were... well not up to code.
It's good to know you work like that. That makes it easier for me if I spot something where I think the coder went


. I haven't spotted such code yet apart from calling the same getDefineINT multiple times at the same location, but the cache killed that speed issue.
In python you can always check to see if the active player has any attribute. So, just like I do to reveal the Trade Screen buttons as a player discovers them you can use that to determine which of the trade screen types or markets are viable at that time. In the LeaderHeadInfos I have added several new attributes like EconomyType and such. At the moment I am just using numbers for those types. Anyway, what I am getting at is we can add the Trade Screens to the LeaderHeadInfos or the CivilizationInfos so each leader can be assigned Trade Screens that they can access. That way you can make a check in python to see if the leader can even use the trade screen and then check to see if it has been unlocked.
I need to figure out some more about python, or rather the Civ4col python engine. Python itself appears to be easy even though I had never seen it before I started modding... way back in May

. It's a mix between C++, perl and bash (3 languages I knew already).
I actually added in three different Enums for the TradeScreens, which could be reduced to just two or maybe just the UnitTravelStateType Anyway, you can look into the :canCrossOcean() function and see the details or rules for each trade screen type. What would be awesome is to add new XML file for TradeScreenInfos and have all the possible rules defined in that XML and then the :canCrossOcean() checks those rules instead of it being hardcoded. That way it would be more modder friendly
I think it should be moved to XML (for several reasons) and then we consider adding them to domestic advisor and stuff afterwards. Presumably something will change and it would mean double python work.
Edit: Also, to get all the info of each different market on the screen I may have to explain to you just how I set the system up. I know its a pain digging through the vanilla code trying to figure out what they was thinking or how the function works.
Generally speaking the vanilla code is close to not documented at all and several mods aren't either. Figuring out the thoughts behind the code can be really tricky.
New work and plans
I moved the cached CvPlayer::getYieldEquipmentAmount() from RaRE into M:C. The cache itself merged just fine with diff+patch, but the loop avoidance code turned out to be a bit more tricky. The idea is that it will know if all yields are 0 by checking a pointer for being NULL and if all are 0, then looping though them could be pointless. However
somebody had to heavily modify a number of the loops, meaning I had to dig into them and figure out precisely what would happen if the value is 0. Luckily all of them can still be avoided in that case

I was scared that inventions would cause problems, but it turned out that they didn't cause any issues at all as they are implemented in a cache friendly way. I didn't change any code at all to fit with inventions.
I didn't do any speed tests, but this cache did reduce AI turn time from 40 to 33 seconds in RaRE meaning M:C is very likely highly affected as well. A similar speed improvement isn't unlikely.
Next up is the cache for CvCity::getMaxYieldCapacity(). Presumably this one will have a constant output as long as no buildings are added/removed. No need to loop through all buildings each time the number is needed. I wonder if it should reset the cache when gaining an invention. That might come in handy in the future, specially since it includes a function, which is called every time a building is added/removed. This gives a perfect place for adding more building related caches.
This is the last speedboost from RaRE, which mean it's the last speed improvement I have planned for M:C for now. However once I'm done I plan on profiling again and I may spot something. Once the slowest part is gone, something else becomes the slowest part.
Also I managed to move transport feeder from RaRE. That leaves the teacher list, though that one relies on TAC school system, which would then have to be implemented first. Since I have no EDU mod diff I can't merge it in as quickly as the stuff from RaRE and it may take a while to implement this.
Also the I spotted room for improvements in the domestic advisor. Presumably I will tweak it in the near future.