In the 2.x branch, the recent addition of the CN feature also added an implicit assumption that "color" will always be in the property cycle. This conflicts with the feature of prop_cycle that it only advances for a plotting function if the user does not specify at least one of the properties made available by the property cycle.

This is important because several plotting functions will make multiple calls to plot()/fill() under the hood, but should have already advanced the cycle. Also, this mimics pre-1.5 behavior of the color_cycle where it did not advance if color was already specified.

The test (which is currently being modified to paper over the problem) which noticed this change is the following:

    fig, ax = plt.subplots()
    ax.set_prop_cycle('linewidth', [2, 4])
    for c in range(1, 4):
        ax.plot(np.arange(10), c * np.arange(10), lw=0.1)
    ax.plot(np.arange(10), 4 * np.arange(10))
    ax.plot(np.arange(10), 5 * np.arange(10))

In the v1.5.x branch, this would result in the cycler not being advanced for the first three lines, and then two lines are made with linewidths of 2 and 4 in that order. In 2.x branch, the cycler gets advanced because of the implicit inclusion of "color" to the property cycle. Therefore, the cycler has a property which is not specified by the user, and it thinks it needs to advance itself. This results in a plot that has three thin lines and then a line of width 4 and then 2 (because of the odd number of plot calls prior).

Now, consider the following scenario:

    fig, ax = plt.subplots()
    ax.set_prop_cycle('color', 'rb')
    for c in range(1, 4):
        ax.plot(np.arange(10), c * np.arange(10), color='k')
    ax.plot(np.arange(10), 4 * np.arange(10))
    ax.plot(np.arange(10), 5 * np.arange(10))

In this case, the cycler will not advance for the first three plots, but will for the last two -- as expected. This difference in behavior will cause confusion among users, and will be very difficult to explain.

I shall re-iterate my design concept behind the property-cycle feature that I added for v1.5: "Color is not special!". I am fine with having a failover mechanism for "C0" in the case that color isn't in the cycler, but to actually modify the cycler provided by the user only leads to confusion. What would we do when we want to expand the "CN" notation to other properties? Are we going to start implicitly include them into the property cycle as well?