...And? Feel free to change to backend. Do NOT change the underlying API calls. If I have an API call that my program uses, you are free to do whatever you want to the IMPLEMENTATION of said API call, but if you remove the call entirely and break my program, you are going to have one really ticked off developer.
2.) Linux has much Unix inheritance that is useless or unstable or terribly outdated from that distance past and after many years of research many new improved technologies are entering in tree to fix or remove the dinos[remove of big lock, VSE, tickless, RT, ASLR, Batman, openswtich,virtio,kvm, numa, etc]
Probably because AMD/NVIDIA has a unified driver architecture that is mostly OS independent. Point being, they aren't going to change. Although I'd "love" to hear your definition of "package unfriendly".
4.)sadly not nvidia or amd are package friendly and both need to replace a big chunk of your distro[kernel mgmt, libgl,libglx,ddx,etc] it can get pretty messy and they both seem to love their script and refuse any other option[amd is bit better here since they open documentation and r600g is a native driver]
Unified code is cheaper to maintain, and should be mostly OS independent. With the exception of any OS API calls, there really shouldn't be any reason to not use a unified code architecture.
5.)nvidia and fglrx driver code is not linux native code beyond the most basic[0.5% maybe] and the same is true for windows, they use 99% of the code for windows and linux [that is why the nvidia/fglrx drivers has more LOC than nt/linux kernel added togheter] that its what alien means and that 99% is an .o precompiled blackbox that only nvidia know wtf it uses internally<-- this is not the proper way to write a driver in any os is just the cheaper way to do it