You're really simplifying things far too much than they really are. Major pain would be boot drives - starting with bioses capable of understanding 4kb drives. Then either providing 512b -> 4kb translation (1) or going natively (2). In the latter case, you would automatically make old int13h interface incompatible relying only on extended int13h. In reality, bioses are often bugged as hell (if you're curious, get sources of e.g. syslinux and read the coments and code inside functions doing i/o). The potential for bugs in (1) is probably astonishing, relatively to stupidity bios makers are capable of, or concepts they have and sadly implement
If you go (2), then you need mbr code (+ eventually more exotic thing like mbr->gpt handover) capable of dealing with 4kb drive as well. Then you need bootmanager/loader/whatever capable of handling 4kb drives.
If you go (1), mbr + loader doesn't need any changes, but then at OS level, you have partition layout (for 512b) completely mismatched with how OS sees the drive (for 4kb).
In context of M$ windows (all of them) and bios, you can forget anything that involves booting from 4kb drive and/or gpt. Your only choice is a board with EFI firmware, which should be 4kb ready (assuming current windows are in context of booting from such drive, and I won't bet my head they are).
With non booting drives the case is more simple (assuming bios won't hang when it sees 4kb native drive, or if you hotswap the drive after booting). Even 2000/XP should be perfectly fine here.
512b "emulation" (which is barely one) provided by drives is really pretty optimal solution, all things considered. And comes at practically no cost (assuming reasonable user and non-ancient OS).
Rather Microsoft and bios coders are, if you /really/ want to blame someone/thing. The real thing to blame is that magical 512 bytes have been assumed and hardcoded in almost everything since 1980s.