Is it geometry or pgfpages bug?
This is not an answer, it is a description of the problem. I am assured that this will be addressed soon in a proper manner.
The way that pgfpages (and its extension, pgfmorepages - which I maintain) works is by saying to LaTeX, "You build the entire page exactly how you want to, then just before you ship it out, I'll take it and squirrel it away for later consideration.". Then at a later point, they say "Right, now I want you to ship out exactly this page.".
From that description, it is hopefully clear that pgf[more]pages needs to interrupt the shipout routine at the very, very last moment. The page needs to be complete, including headers and footers, and backgrounds, and borders.
From poking around in the latex.ltx code, I can see that the LaTeX team have been working behind the scenes to streamline the LaTeX core. Part of that involves putting hooks at various points to allow packages to hook in to various routines in a more orderly fashion than has been previously possible. I guess that the purpose of this is to sort out the mess that is conflicting packages who all try to redefine the same command, environment, or routine.
With regard to the shipout routine, therefore, the new LaTeX kernel adds in its own code at the point of shipping out a new page which provides access to all of these hooks. One of which, by the way, is used by geometry to put the frame around the page (geometry doesn't know this - thanks to the wizardry of the LaTeX team an awful lot of packages should just work without modification).
So at the moment we have a race condition in that both LaTeX and pgf[more]pages are trying to insert their code into the shipout routine and both work by replacing \shipout by their code. The order that should happen is that LaTeX's code works first and then pgf[more]pages second. Unfortunately, as LaTeX is loaded before pgf[more]pages, actually what happens is that pgf[more]pages is executed first and then the LaTeX code. This means that code such as geometry's showframes is only executed when the page is actually shipped out and not when pgf[more]pages stores the page. This is why the frames are incorrect.
What appears to be needed is a "Right before shipout" hook that allows pgf[more]pages to swoop in at the last minute. That currently doesn't exist, however from comments from the LaTeX team it would appear that they are aware of the issue and will address it shortly.
The issue has been temporarily resolved by adding a fix to firstaid (as part of the LaTeX format). This has been send off to CTAN so it should reach the major distributions today or tomorrow and from that point onwards should work again as before.
As @AndrewStacey observed the kernel needs to provide an interface to take over control at the very end of building up a page just prior to shipping it out to the dvi/pdf file as an applications like pgfmorepages want to add further control on what happens at this stage (instead of simply shipping the page out).
However, this can't be done through a "hook" of the new hook management as this is not about adding additional code (where several packages could add code and the only question to resolve is in what order) but it is about changing the process and only one process can be executed.
The model here has to be one where one process can be swapped in for another but only one process is ever active. My tentative term for that is that of a "configuration point" and we are currently working on iron out the interfaces and concepts for that. Once that is available we will work with package maintainers how to apply them and then take out the current "firstaid".