The intuition library is a major change, but not even (to the major degree) my change. The problem with the original intuition.library is that it was compiled with a compiler that is no longer available, namely greenhill C. We only have SAS/C nowadays. Both compilers have advantages and disadvanages. SAS/C has registerized parameters (function parameters are passed in CPU registers), is more modern and speaks ANSI-C, and supports creating operating system components. Greenhill C is an old K&R C compiler with an optimizer that is better than that of SAS/C at times, but it supports only stack-based function calls and hence depends on "register ping-pong stub functions" between the Os function and the implementation. It also supported a neat trick where short structures (such as a rectangle) was passed directly rather than making a copy, a trick a couple of functions depended upon.
In 1993, the intuition greenhill C code was ported by Peter Cherna to SAS/C, which was a tremedous work because it required touching a lot of legacy K&R C functions to ANSI C and fixing (or providing) all the function prototypes. Greenhill C was very lazy about pointer correctness, so casts were missing all over the place, and parameters were passed in and out in a rather leeway approach.
Now, unfurtunately, two other players enter the playground, and these are P96 and CGFx. Due to their very nature, they depend on the register and stack allocation exactly as performed by the Greenhill compiler because they have to solve the problem that some features they need are simply not accessible through the official intuition interfaces. Just to name one: When allocating the bitmap of a new screen, they need to know how the memory is organized and which viewmode the memory should be used for, i.e. truecolor, hicolor, indexed, planar... but intuition does not deliver this data. So, they just grab the data from registers where it happend to lie around "by pure chance", left behind by the code compiled by Greenhill. Under SAS/C everything is different, and registers and the stack is used differently, so the hacky approach taken by both RTG functions do not work anymore.
For P96, it is known which parameters it expects where, so a "kludge" function in assembler just provides the missing data. "It is known" here means that there is a common subset of people that have access to P96 *and* the Os. For CGFx, this is not the case, so it remains completely unclear what exactly CGFx expects, which interfaces it needs and how we could provide them. We contacted Frank Mariak on the problem, and would be happy to provide intuition V45 to him to integrate CGfx into this release, and/or provide similar kludge functions or interfaces to make it work. Unfortunately, at this time not much happened yet, but we all hope that 3.1.4 will become successful enough to make it an attractive development target.
Now for my contributions: This is not really that much. One thing is that you can drag windows out of the screen. This is actually less than it may look because it is primarily a job layers has to do, and layers was already modified quite a while ago to support this service. Intuition was only modified to make use of this service, and its "window movement" functions where adjusted for testing the window bounds differently if the feature is enabled. This is by default on the workbench, but not on custom screens, but every constom screen can request it by a flag or a tag.
Second, a less known feature is that intuition now places windows under the mouse pointer in case the window does not indicate a target position and allows auto-adjustment of its position. Hence, if you open up a preference program or the workbench "execute" or "rename" dialog, then they will pop up under your mouse and not on the top-left edge of the window. This is hopefully more useful, and intuitive (well, wasn't that the purpose of intuition in first place?).
Other minor changes are that autorequests now allocate a larger stack - the previous stack was really tight and less than 256 bytes were left , which - if additional patches were in the sytem - caused stack overruns. The other fix was an off-by-one error in allocating the name of a public screen which could have crashed memory.