Nope. Not that simple. Note that I'm not saying it can't be done - it absolutely can be. It's just that what you describe sounds very simple, but the implementation of it requires a significant amount of new code and changing existing code's behavior, which in turn increases complexity and requires significant testing to insure no ill side effects are unintentionally introduced.
First off, I'm guessing here about the code implementation, but it's reasonably straightforward so I shouldn't be off much.
Currently, there's a structure that holds the location of all the buildings on a planet. Each location likely has a flag, too: Built/Not Built. The "Not Built" flag is for stuff in the build queue. The current algorithm walks through the structure, doing all the calculations necessary, and ignores that buildings with the "Not Built" flag. Later, the "builder" function runs at the end of the turn, looks at the Build Queue, and calculates if the top building is finished. If so, then it changes that building's flag to "Built". Rinse, Repeat.
Now, for your feature, I have to modify that structure-walker to not only count the "Not Built" building, but then go over to the build queue and figure out which of those "Not Built" buildings is next, so I can display the calculation based on using just that one additional building. And NO, you can't say "well, I only want to see it for the building I just placed", because that would absolutely destroy the concept of the build queue by forcing only one building to be placed at a time. You'd also have to build in sufficient code to handle when someone reorganized the build queue.
The problem boils down to this: you're assuming just a single instance: nothing in the build queue, placing just one new building, and asking for the computation to be done to show the projection. We can't support that. The General case has to be solved instead, which involves multiple buildings in the queue, possibly being reordered.
You can't put sufficient constraints on your feature without avoiding a general-case solution, because we want to support the general case of having a build queue. In addition, the "Hover" feature is programmatically no different than what you're proposing; you do the exact same amount of work trying to keep track of what's being built, what isn't, and how that impact everything. That is, your ask is no less complex than the Hover feature, it just does it only once rather than as you move the mouse over the spaces.
The end result is that you're doing far more than just issuing a recalculation on the "new" building map. It's a whole lot of new code that touches multiple parts of the system. Little of it involving the new counting, but lots of it handling the extra bits of information and decisions that need to be made to set up things for the counting in the first place.
---
All this is a bit academic, because, frankly, the feature doesn't provide much of anything in additional information to the user. It's not really relevant that you know Planet X produces 96 rather than 95 manufacturing. That is, the absolute number is useless (unless you're doing completely idiotic levels of micromanaging, in which case GC3 should NOT indulge that behavior). What you're interested in knowing is approximately how much it improves. Particularly so you can chose between improvements and/or locations. What you're after is figuring out whether putting building X in location Y is better than putting building W in location Z. All this feature does is provide a bit of a crutch; it doesn't actually address the "optimal building" placement problem.
Like I said above, this is a feature better suited to human brainpower, as it can do the rough calculations far faster and easier than the computer can, because the computer is trying to solve the general case (since it cannot be told to only limit itself), and all you care about is the specific instance.
