IMO the major challenge here is semantics, scope and API design and that will entail the same topics as #29826 (comment), which lead to stalling in that thread. After all, we should have a consistent story between 2d and 3d. - I suspect to move forward here, we have to pick up the discussion from #29826.

While I think the more substantive discussion/change is likely the API discussion above/in the issue linked above, a small technical note that the test failure on ARM (at least, logs are gone for the azure) does appear to be a small deviation in the image, most likely due to rounding modes on the CPU architecture (RMS 0.001) so adding a tolerance may be necessary.

This PR is similar to Vector #22435, and is intended to plot 'data' rather than 'annotate'.

However the Vector PR is currently inactive. It seems like this is because of the presence of another function annotate() which could be called without text to achieve similar results in 2D. However, I believe this does not apply for this PR as there is no annotate3d method.

If there are plans for Vector to be merged, I could follow the same API (mentioned in this comment) for this PR and also rename the function from arrow3d to vector3d. Now, as this used to plot 'data', it can also be changed to follow a certain color cycle by default.

I would like to know your thoughts on these @timhoffm

@AdwaithBatchu as written in #30517 (comment) I think we have to first solve the 2D case to ensure API consistency.

We currently do not have the resources and priority to work on that.

This unfortunately means working on arrow3d is blocked.

As a temporary solution, you could create an example in the 3D section of our gallery, containing arrow3d as a standalone function. So that there is documented way how to draw 3d arrows, but we don't have to set an API in stone yet or ensure coverage of edge cases.