I'm not sure if arbitrary markers can be rotated, but markers can take a generic (numsides, style, angle) tuple that seems to work for your purposes:

ax = plt.gca()
for i, angle in enumerate(np.arange(0, 360, 60)):
    ax.plot(i, i, marker=(1, 1, angle), ms=20, mew=2)

@mwaskom no good sir, what you said is wrong, I challenge you to reproduce my image with your method... or don't waste your time and I explain you why, the tuple you used creates a regular polygon as a marker, i.e. a line (as you did) an equilateral triangle, a square, pentagon, hexagon, heptagon, etcetera... so you are not far, because if this tuple also accepted a "text" argument, them we would be set, in fact that could be a solution, add a "text" argument to this tuple, that rotates any given text as a marker.

I don't see any reason not to add (with proper documentation and tests of course)

    def rotate_deg(self, rotate):
        self._transform.rotate_deg(rotate)

to marker.py, and indeed I don't see why #2478 was so convoluted and didn't use the transform.

(Also, please @Polirecyliente, lets try not to "challenge" people who are trying to help!)

no good sir, what you said is wrong, I challenge you to reproduce my image with your method

The problem in your example appeared to be placing small tick marks on a plot with arbitrary rotation. The more complicated marker is just three tick marks with the same angle and small offsets from each other. While not as simple as a single marker with a rotation parameter, that could solve your problem immediately rather than waiting on a change in matplotlib. One can also imagine writing a small function that abstracts the drawing of a triple tick mark in your code. But as you say, it seems like offering further helpful suggestions might be a waste of time...

I think @jklymak suggestion of adding a rotation setting (and letting it come in through the__init__) is a step in the right direction (which will handle cases where we want to have the same rotation on every marker in either plot or scatter), but I also think we should revive #2478 again (which will handle the case where we want each marker in a collection to be rotated differently like we do in quiver / windbarb).

attn @brunobeltran

Is this something @brunobeltran was working on?

A very quick look at collections.py seems there are quite a few ways it could be modernized, likely by just making the top-level class always have a self._transforms property, and making it a list of real transforms (sometimes it is just nx3x3 matrix). That may be a little wasteful for some artists that can't use it, but they could always zero it out. Oddly Collections.__init__ does not define a placeholder, but Collections.set_size sets self._transform.

Once that is all done, it seems set_rotations is an easy next step.

Bruno has been doing a bunch of work on the Marker class.

For the sake of completion, I must say that rotate_deg is not the only marker function that is private, there is also skew, translate, scale, and rotate (in radians), all those should be included, they are useful, I've used both rotate_deg and scale, and all of these are methods of the _transform property of markers.

Right, its the transform that is private, but passing around transforms can be problematic. But we could possibly take a transform argument when we make the marker.

But we could possibly take a transform argument when we make the marker.

That sounds reasonable. I'd add the limitation that a passed transform should not be modified afterwards (e.g. via set_matrix). I suppose we might want to combine the passed transform and the internal _transform and we don't want to keep track of both and possible updates. Also, changing marker transforms later will be an even more rare use case than just transforming markers at all.

The API would be something like

MarkerStyle(r'$|||$', transform=Affine2D().rotate_deg(45))

which is a bit bulky but IMHO still ok and it lets you specify any transform you want.

#20613 (comment) also makes the case that joinstyle should have a public interface.

marking as a "Good First Issue". Getting the API change right is a bit tricky, but not technically difficult. It will require tests, and ideally additional documentation wherever MarkerStyle is discussed in depth.

I would be very happy to contribute to this feature. From the above discussion I am thinking of two implementations,

1. Implement the following function append_transform(**kwargs) or set_transform(arg).
2. Implement public functions like skew, translate, scale, rotate, etc in the "matplotlib/markers.py" itself.

This will be my first contribution, I appreciate any help, if I have misunderstood anything or any suggestion will be great.

Hi, sorry to interrupt, I was slowly working on this issue last couple of weeks. I was slowed down by some issues with copying/deepcopying of Path.

Has #20914 resolved this?

I believe so.

Closing then, as that PR fixed it.