I'm not a driver developer so I can't speak to that entirely. Since with DirectX12 and DXGI 1.4 the swapchain backbuffers technically belong to the desktop compositor now (afaik), instead of to the application like they did in older versions, that could be the obstacle. Honestly I'm not sure how a driver would get around that, it'd require the driver downscaling the backbuffer for the compositor, yet still permit the compositor to offer the oversize backbuffer to the application for rendering. Really it would be simpler for DX12 drivers to do what the current crop of DX11 injectors do to add postFX and downsampling - intercepting the API calls at the application level rather than the driver level, creating a high-res intermediate buffer that the application thinks is the swapchain backbuffer, and downsampling that into the actual swapchain backbuffer that the compositor owns.
G-sync and freesync I'm even more ignorant about. I'd imagine the problem is that currently the app presents to the compositor at one rate, and the compositor then presents to the screen at a fixed rate (60hz). The fullscreen exclusive solution is that while the application is the only client of the compositor, the compositor will present to the screen at the same rate as the application (I think). I would imagine a windowed solution to the same problem is the same one - allow/force one client of the compositor to override the compositor's screen present rate even when the compositor has multiple client apps.
Like I said i'm not a driver guy, so take all that with a pinch of salt. My understanding from the app side of things is that the driver teams are still ensuring their drivers meet the API specs (as the AMD driver thing illustrates), before they then start trying to break from the specs too much.