Technically, it's tested, though the test wasn't strictly designed to do so (#18156). Not sure if I should write a different test.

How can this have been tested? The behavior was broken and is now fixed, but you did not have to change anything in the tests.

That lines up with where codecov says exactly 0% of the lines of code touched in this PR have been executed by the test suite.

Sorry, I guess what is tested is theopposite case. I can write up something that should cover everything.

I pushed a more extensive test, and also found that linewidth was not correctly propagated, so fixed that as well.

There's still a bug in#18287 in that initial draw is not correct, but any change in the view angle re-calculates stuff so it appears correctly. I think there's some stale trigger missing inview_init, but need to investigate that for a bit.

I'm very confused about this initial draw thing. To be clear, this PR does fix the sorting, which you can confirm by running#18287, and then rotating the view of the first figure so that the markers's depths are reversed.

However, on the second figure, the face colours of the scatter markers are not sorted, though the edge colours are. Inserting adraw (of any kind, lazy or forced) just beforeplt.show() magically fixes it. As far as I can tell,Path3DCollection.do_3d_projection sorts everything exactly the same way on both draws, but somehow it doesn't reflect that in the result.

I'm happy to merge this as-is without tracking down why the initial draw is wrong (which is not to say that isn't a bug that needs to be fixed).