@Nathaniel I think developing the color-overhaul as a maintenance release is a decent compromise. All non-color changes get directed at the master branch and we can cherry-picked back bug-fixes as needed.
The next feature release is planned for July/August, I really hope sorting out the colors does not take that much longer. if we start to Paint a Bike Shed that just needs to be shut down.
I am not sure how I feel about a default non-trivial style-cycle. +1 on providing the machinery and rcparams to do it and agnostic which branch it goes on.
@Olga I think there are two separate issues, the default color map used by ScalarMappable and the default color cycle that ax.plot and company use. I think both should be up for discussion and do not need to use the same colors.
Tom
···
I’ve made a second notebook that uses the IPython interactive machinery to let anyone play with the parameters and explore different ways of setting them. you can download the notebook with that here: http://nbviewer.ipython.org/gist/mwaskom/842d1497b6892d081bfb (I made it using IPython 3.0rc1; I’m not certain if it will work on the 2.x series; sorry if that is the case).
This stays with the general approach in the original notebook of using a linear ramp for chroma, which again maybe is not what we want. But it should let you get a better sense for the parameter space.
As I said in the email to Olga, I think (a) I would advocate fairly strongly that matplotlib should design a custom colormap as its default, and (b) I think this approach (a cubehelix-like map in Hcl space) is a principled way of doing so (though maybe not optimal). But both of those points are independent of whether you end up going with the particular parameters that I used to generate the original proposal – I have my own domain on which to impose my personal aesthetic preferences, and I don’t need to take over matplotlib too 
(But I do think it’s worth distinguishing the matplotlib default from the matlab default.)
Michael