Thanks for the clear report. The PathCollection object doesn't keep track of NaN data, so the set_colors method only acts on existing markers. Its debatable which is the correct behaviour, but you could just as easily see someone complain if it were setup the way you'd like it. There are two workarounds: either set the colours at draw time (your method 1), or edit the color array before sending to set_color.

I have a vague memory of a fix for this going in for 2.1.

Sorry, should have said I reproduced in master.

To elaborate: the strategy used by scatter is to filter out all invalid data at the start, regardless of which input variable has the invalid or masked value. Then this filtered data is used to make a PathCollection which is returned. Because the invalid values can come from any combination of the input variables, including position as well as color value or size, it would be awkward to try to maintain the original data shape in the returned PathCollection. It might be possible, but I'm not convinced it would be worth the added complexity.

If filtering is done using a variety of input parameters, then I would think it would be even more important to keep track of the invalid data mask, so that data sets (with possible NaN values) could be used naturally with the programatic api. I think that doing so would greatly help with NaN support, but more generally help make the connection between data sets and plots simpler.

In certain types of scientific analysis NaN is a valid and meaningful floating point value that needs to be retained as part of data sets. Requiring fre-filtering before plotting is of course an reasonable option, but then it would still seem that there should be consistency between the original call to scatter and the api.

I agree that the inconsistency you point out is undesirable. The questions are, what are the options for removing the inconsistency, and is the trade-off involved in the best of these worth it?

I think the simplest way to handle this might be to give collections one more optional initialization argument, a mask, which would then have to be applied in appropriate method calls, perhaps depending on an optional kwarg in the method call itself.

A better alternative might be to warn about this inconsistency in the scatter docstring.

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

This behaves as expected now, likely after the PR linked above.

There is no PR directly linked above, but yes, it was fixed by #12422.