The release plan for Xserver 1.5 and Xorg 7.4 was discussed during the X.org Developers' Summit in Cambridge (September 10-12th). This is what we expect to ship with Lenny, so here are some details about the upcoming.
As usual, there will be a 6 months release cycle. So Xorg 7.4 is expected on March 1st, 2008. There won't probably be any new Xserver release before that since some changes (already merged) require all drivers to be updated anyway. So Xserver 1.5 is expected on the same date.
Since there are already some known problems in Xserver, they also plan to release Xserver 1.4.1 on November 1st.
The master branch of Xserver already contains the long-expected pci-rework which is supposed to fix all the PCI domains and other non-trivial PCI hierarchy support (important for ia64, but also for some powerpc and sparc users).
People having Intel, ATI or recent Nvidia boards learnt to love the RandR 1.2 extension which provides the ability to enable/disable, resize, rotate, move outputs within a single big virtual screen. More transformations should be possible with RandR 1.3. Hopefully, there will also be some standardization regarding output names in various drivers, or at least a way to retrieve the type of each output (LVDS, DVI, VGA, TV, ...). And the server should get an abstraction object to describe GPUs, which might make the support for multiple boards easier.
On the input side, XKB 2 and XGE should be merged, which shouldn't be really visible to end-users but should make internals much better. Then MPX (Multi-Pointer X server) might be in Xserver 1.5 too (if all semantics issues get fixed first). It would mean support for multiple independent keyboard/mouse pairs or so. See the MPX page for details.
Compositing still gets a lot of attention. Several distributions are actually thinking of enabling Compiz by default. EXA (the new acceleration architecture that has been designed for compositing) got improved a lot in Xserver 1.4. Several drivers including Intel and ATI r300 already work great with EXA (no need to use XAA + XAANoOffscreenPixmaps anymore) which means Compiz works very smoothly, even when resizing windows. XAA won't be removed soon though since lots of things needs to be fixed before that. There are also several videos available online, like this one.
But one big piece is still missing for compositing: directed rendering to redirected windows. So far, if you start glxgears in Compiz, you will see that the gears completely ignore wobbli-ness of windows, other windows overriding them, cube rotation, ... they keep rendering of top of everything without any effect. Getting true support for compositing such windows requires lots of work in all parts of the DRI stack. Kristian Høgsberg got it to work (and we even get a great demo). See Kristian's blog for details. Upstream devs are now working on integrating all modifications nicely in upstream Xserver, drivers, DRM module, Mesa, ... Once this works, you can get GLX_EXT_texture_from_pixmap for both direct and indirect rendering, and full support for GLX 1.4 in the server (only 1.2 is supported as of now).
Also, redirected windows (let's say a wobbly window on a side of Compiz' cube) should get input events correctly thanks to input transformation in Xserver 1.5 (event coordinates will be converted into the redirected window coordinate space before being passed to the client application).
Compositing improvements actually require a large rework of the memory management in the server. Basically, we need a global management for both 2D and 3D object allocations, so that you can get both to work fine without having to change config options (things like XAANoOffscreenPixmaps or FbTexPercent). All this is related to the TTM (Translation Table Maps, see these slides for details) which has been under development for a while. It requires to change the interface with the kernel DRM modules, and it won't happen before 2.6.24. The Xserver part of the work is not big, so it might still be done before 1.5 is released. Fortunately, once all this is ready, people should stop complaining about memory allocation failures, Compiz being slow because one option is not enabled by default, ...
Another hot topic in the X.org/kernel area is about moving modesetting in the kernel. When you get a kernel panic, you only actually see it if not running X (or if logging kernel messages through the network). So your machine freezes, you don't know why, you have no way to know, and you just reboot. Getting panic messages on X would be much better. To do so, the kernel needs to now which mode is currently in use on the monitor and then it will render the message on the framebuffer. This require lots of work, so it will unlikely be in Xserver 1.5 though.
Xserver 1.5 will also contain XACE (security framework), the cleanup of the ABI (explicit _X_EXPORT required), and possibly glucose (OpenGL acceleration for X, see Zack Rusin's blog).
I asked whether there was actually some work on building the GLcore server module as a part of Mesa so that building Xserver does not require the whole Mesa source anymore. People seem to agree the current situation is a real pain for distributions and we should make this change happen. But the actual work has to be done in Mesa anyway, we'll see what happens.