If you look at the current framebuffer console layer you will see a lot of replicated code and and huge amount of code handling tty/console functionality.
The primary goal is to remove the console code from fbdev and place it into fbcon.c. This reduces the code and makes writing a new fbdev driver easy since the author doesn't need to worry about console internals. It also allows the ability to run fbdev without a console/tty system on top of it.
First the roles of struct fb_info and struct display have changed. Struct display will go away. The way the the new framebuffer console code will work is that it will act to translate data about the tty/console in struct vc_data to data in a device independent way in struct fb_info. Then various functions in struct fb_ops will be called to store the device dependent state in the par field in struct fb_info and to change the hardware to that state. This allows a very clean separation of the fbdev layer from the console layer. It also allows one to use fbdev on its own which is a bonus for embedded devices. The reason this approach works is because each framebuffer device, when used as a tty/console device, is allocated a set of virtual terminals to it. Only one virtual terminal can be active per framebuffer device. We already have all the data we need in struct vc_data so we shouldn't store a bunch of colormaps and other fbdev specific data per virtual terminal.
As you can see doing this makes the con parameter pretty much useless for struct fb_ops functions, as it should be. Also having struct fb_var_screeninfo and other data in fb_info pretty much eliminates the need for get_fix and get_var. Once all drivers use the fix, var, and cmap fbcon can be written around these fields. This will also eliminate the need to regenerate struct fb_var_screeninfo, struct fb_fix_screeninfo struct fb_cmap every time get_var, get_fix, get_cmap functions are called as many drivers do now.