Well, yes
Amazon has changed the extension when they've changed the format (.azw, .awz3). Kobo hasn't changed their format yet, so we don't know what they would do. But it would be trivial to say "open the ZIP file, look for this file with these specific contents; if present use the new format parser" and keep the same .kepub.epub double extension. Either way, we could play that cat-and-mouse game. Now that you make me think about it a bit, it feels like a code maturity thing. Kovid made the decision to incorporate AZW and AZW3, but it's my impression that the code around that is much more mature and stable than the KePub code is.
Who knows, perhaps someday if I can produce KePub files nearly as well as Kobo can perhaps Kovid will want to incorporate it all into calibre core despite it being site-specific and not near-universally preferred. If he does I'll happily make the patches to bring everything in, but I'd think that would also need a bunch of work with davidfor to merge the code in cleanly; if KePub is coming into calibre core it shouldn't be as yet another driver. A huge chunk of my problem is that I can't justify purchasing a book from Kobo (they're so expensive, and nothing I actually want is eligible for coupons) but I need a recently released book from them to make sure I'm generating KePub files that work like their current releases.
How about this: if someone has a recently released (say, released during the month of June) well-formatted English-language KePub file they've stripped the DRM from and they're willing to email me privately, I'll put in another effort to get the plugin code generating better KePub files. A lot of the recent updates have been made based on books that are a few years old by now, and I think Kobo has made some internal improvements to how they generate KePub files since then. If Kovid wants to bring KePub into core calibre and David doesn't object to me merging the drivers, I'll also dedicate a good chunk of my copious spare time to the patch to integrate it all to calibre.