Launching these new unmodified Second Generation runtimes required us to develop new security and isolation technology (based on gVisor [1]). This allows us to securely run arbitrary code on shared data centers with isolation guarantees. This took us significantly longer than expected. The good news is, now that we have this new stack in place, we should be able to deliver runtime updates significantly faster.
That said, they don't quite go into the details of what type of isolation is missing from standard containers - I'm curious. It does seem like it would have been ideal for everyone if LXC would have had better isolation, rather than having to run a userspace kernel emulator thingy for each container, but c'est la vie!
I work on gVisor. The answer is that having a separate kernel is required to achieve a high degree of isolation and by definition Linux containers share a kernel with the host. A separate Linux kernel could work as well, but gVisor tries to achieve a different set of trade-offs.
Very few people were demanding Python 3 support 10 years ago. Prior to 3.4 uptake was limited so we’re really talking about 4 years.
Also, old appengine was built with nacl (remember that?) sandboxing. Anything that couldn’t be built under the nacl sandbox couldn’t run in app engine. Google realized this was a problem long ago but it takes time to rebuild your whole platform to eliminate such a fundamental dependency. That may have taken most of their focus, leaving little for other projects. and of course their new arch makes python 3 free so it’s difficult to have a parallel engineering effort that will be rapidly deprecated.
