I also considered doing this as a new marker (tick), but it’s a little harder to control the size of the ticks when using a marker since it scales with the stroke width. The arrow-reverse marker is already pretty close to this, though!

As I mentioned in #1892 I think I prefer the marker version, for this particular use case.

However, the up-side of changing the node type to a PATH is that it allows it to be more malleable. If we did this across the board, not just for rules, we could have rules on maps (#1164), "curvy rects" (for example to create donut charts as rects displayed with a polar projection). Paths are very versatile and could be used to do something unexpected (like, be used to control a textPath, or add a perturbation/disturbance for style effects, or add a flubber transition to another type of shape). Another use case would be "top rounded corners" (#1201). {maybe this comment should be an independent issue}

the up-side of changing the node type to a PATH is that it allows it to be more malleable

There’s no requirement that a mark always render as the same type of SVG element; it could render as a line sometimes, and a path other times when more expressiveness is required. For example, the dot mark renders as a circle element for the circle symbol and as a path element for other symbols.

I don’t think the implementing SVG element should be the primary consideration here — that’s mostly invisible to the user. Instead, we should decide based on the difference in the two interfaces:

1. In the path approach: the ticks inherit the rule’s stroke options (stroke, strokeWidth, strokeOpacity, strokeDasharray, strokeDashoffset) and the tick size is specified in (absolute) pixels. This approach applies exclusively to the rule mark.

2. In the marker approach: the ticks inherit only the stroke of the associated mark, the tick size scales with the strokeWidth of the associated mark, and the other stroke options (strokeWidth, strokeOpacity, strokeDasharray, strokeDashoffset) are not configurable. This approach applies to any mark that supports markers.

I think if we’re happy with the limited configurability of ticks, then (2) seems preferable to me due to the added generality. But we could always add (1) in the future, too.