Disclaimer: Not a dev just somebody who follows the mailing list. So some details might not be completely correct.
This means that eeschema will use open gl (or cairo) to render its drawing canvas. This is the same thing that happend to pcb_new when version 4 got introduced. But as the renderer will not reduce the feature set, there will not be a need to keep the old renderer alive for eeschema.
Python 3 support is not the primary goal. The problem is with a library called GTK and wxGTK. This libraries are responsible for rendering everything that is not rendered by open gl / cairo (so everything outside the drawing area) More precisely the problem is with a python library that connects to wxGTK. (This library is called wxpython) This library needs to be compiled against GTK2.x for KiCad. But most modern linux distributions dropped support for GTK2 quite some time ago.
So they use the library that is compiled against GTK3. Sadly the lib that is compiled against GTK3 also changes some interfaces. This means it is not compatible with KiCad. (I do not fully understand the full details of it. For that you would need to talk to the devs.)
Scripting will still work. As long as it does not need anything from wxpython. Sadly the footprint wizards and KiCads python console need this lib so they are deactivated if WXPYTHON is off. Scripts that include wxpyhton for any reason will also not work when this flag is off.
Yes. Definitely to the schematic and symbol file format. Possibly small additions to the footprint and pcb file format.
The schematic file format is quite outdated. The plan is to transfer it over to s-expression. this is the same underlying format that is now used for the pcb side of things.
The reason is that the devs want to add much more functionality to the symbol and schematic.
Right now the alias functionality of symbols is very limited. The plan is to have something called inheritance in the symbol file format. This would allow much more flexibility when dealing with symbols that can share parts of each other. (However the full inheritance support might be postponed for version 7. Version 6 might just re implement the same functionalities as already exist in version 5.)
Another planned addition is pin aliases. So you can more precisely model multi function pins of say a micro processor. (Again this might not be included in the first round of transferring over to the new file format)
And a more powerful “bus” support has also been proposed. One part of it would make hierarchical sheets a lot more powerful. (You could then for example have a hierarchical pin that represents a full SPI bus that includes MISO, MOSI, CLK and CS. Allowing much more abstraction.) There is also talk of having intelligent bus entry points (so you already get labels suggested that fit the current bus)
There are a lot more things planned. The stuff i listed is only the stuff where i remember somebody mentioning that this would benefit from the new file format. (I am sure there are even more things that will benefit from it.)