On Monday a change was submitted to bump the ABI version number (to 18) for the X.Org video drivers as a result of some cursor changes. This quickly raised concerns by NVIIDA's Aaron Plattner since this breaks the ABI against xorg-server-126.96.36.1992, which happened now that the X.Org Server 1.16 merge window closed and the code is into a bug-fixing state and thus should have a frozen API/ABI. The ABI breakage could be trivially fixed, but it wasn't.
The ABI break was attributed to a "temporary mistake of changing the function return type as a bug" so that existing drivers retail API compatibility with the new X.Org Server version, with the most important driver to Keith Packard as the X.Org Server maintainer being that of his employer -- the xf86-video-intel driver. NVIDIA has already been working on X.Org Server 1.16 support for their proprietary driver but this event has thrown an issue into their handling of their new support.
NVIDIA's Aaron Plattner ended his X.Org mailing list statement with, "This last-minute bumping of the ABI in what is supposed to be a code freeze happens rather frequently. Since this seems to be the preferred method of doing things, do you want to go back to the way it used to be, where the ABI is only really officially frozen once the .0 release comes out? I can certainly hold off adding official support for new ABIs until then, but please note that that will delay adoption of the new X server by distributions significantly due to the reasons I listed above."
Keith Packard of Intel responded with "1.16 is scheduled to be released at mid-year, we've still got two months to go. The freeze process for the X server takes half of the development cycle, and we're now one month into that. I'm not willing to ship 1.16 with the API that was released at the feature freeze; it has a bug where existing drivers would build and mostly run, except that cursors would fail in mysterious ways. That's clearly not acceptable for the 1.16 release. We either need an API change that breaks compilation (so that users are forced to fix them), or a cross-version compatible API. A cross-version compatible API is obviously preferred as that will allow people to separately migrate driver packages to the new API as they please."
At the time of writing this article on Monday evening there's no solid answer what will be done for X.Org Server 1.16, but we should see soon enough.