while adapting cmyt to this change, I noticed that LinearSegmentedColormap still silently accepts the parameter N, shouldn't it be deprecated too ?
(same goes for LinearSegmentedColormap.from_list)

The effect / usage of N in LinearSegmentedColormap is different:

• For ListedColormap it only cuts or expands the given list of colors, which can easily be done by the user.
• For LinearSegmentedColormap, N defines the internal sampling. The input are RGB curves, which may be very coarsly defined via only a few points. Because we don't want interpolate these curves for every color lookup, LinearSegementedColormap internally samples these curves into a lookup table. N controls this sampling. If we would remove N here, that means the user would have to do the sampling, and then we'd be effectively back to a ListedColormap. In other words, the added benefit of LinearSegmentedColormap is that you can specify the RGB curve on a high level, and the colormap does the sampling into a lookup table for you. That fundamentally needs N as a control parameter.

LinearSegmentedColormap.from_list is only a slightly simpler interface that limits the RGB curves to continuous curves (i.e. you cannot have discontinous jumps), it this equally needs N for the internal sampling.

Therefore, there is no plan to discard N for LinearSegmentedColormap.

thanks a lot for this detailed explanation !