Sure. Actually, I was going to write about the changes anyhow, so we can start with intuition if this is most interesting for you.
Actually, there is really not much new here. The V45 added off-screen dragging, and for that modified the check for valid window positions and sizes. Interestingly, this check exists twice. Once in the event handler that processes user mouse movements, and another time when moving the window through the MoveWindow() function. The implementation of the latter had a bug - instead of checking whether the right window border would leave the screen when moving the window left, and then disallowing the move, it checked the left window border. Hence, moving windows by programs already stopped the movement pretty early at the left edge of the screen. All other checks were ok.
Then, there is a tiny "preparation change" in OpenScreen() for rtg graphics. The problem P96 and also CGfx have to solve here is to identify the type of bitmap to allocate. That is, whether OpenScreen asks for a RTG bitmap, a true-color bitmap, a high-color bitmap or a native bitmap. Unfortunately, there were no means to provide this information to the rtg.library, so what P96 did is that it "went fishing" for register contents, and if they looked fine, it assumed that the call was coming from intuition. And if so, P96 goes "fishing for data" on the stack frame, and there finds the view mode of the screen it was supposed to open, and then could allocate the bitmap correctly.
So V45 intuition contains a big kludge to create a "nicely loooking" stack frame for P96.
Needless to say, it cannot stay this way. Actually, this was already clear around ~2001/2002, so back then (remember, already 17 years ago) I extended the interface for AllocBitMap() in P96. If you set a specific flags combination for AllocBitMap() which would be otherwise invalid, its last argument, which is usually the "friend bitmap", becomes a taglist. And on this taglist intuition places now a tag defining the viewmode.
If this first attempt to allocate a proper bitmap fails - and it does by default as the flag combination is invalid under normal circumstances and the graphics.library implementation refuses it - then the old method is used, so compatibility is retained.
Before you ask, I do not know what CGfx would expect here, or how to update the kludge to make CGfx working - or at least move closer to a working cgfx. I don't have access to its sources like I do (and did back then) for P96.
In the future, this "kludge" in intuition may just go away. It is not needed for P96 anymore, and it does not help for CGfx for reasons unclear to me.