I am a bit confused if one should keep the documentation for mpl_toolkit "separated" from matplotlib, i.e., if one should use full descriptors matplotlib.axes.Axes to show that it is a matplotlib class or ~.axes.Axes for brevity...

I don't think we need extra separation when referencing types in mpl_toolkits. So https://matplotlib.org/stable/devel/documenting_mpl.html#referencing-types still applies.

In #19572 you, @timhoffm , suggested to make set_3d_properties private. Is that still your standpoint?

There's also #1482 and partly #1483 which may be relevant to consider.

In #19572 you, @timhoffm , suggested to make set_3d_properties private. Is that still your standpoint?

Yes.

• It should be an implementation detail that our 3D artists are 2D artists with a third dimension glued on. set_3d_properties leaks this concept. Having this public would make it much more difficult to replace Artists later with proper 3D Artists, in case we see the need for it.
• The API is confusing: I can update x and y with one function, but have to use another function for z. That's weird. - Problem: We do not have actual 3D data setters in many cases. set_3d_properties is currently the only way. Before we can privatize it, we need a proper 3D set_data API.
• The API is inconsistent between different Artists. Migrating this API to a homogeneous set_3d_properties interface is likely at least as much work as deprecating and providing set_data.