The source of this is likely that this code is also used to validate reading matplotlibrc which always comes to us as strings. The impacts there need to be understand and balanced with any fix to this.

Yes, the validators accept two kinds of inputs: (1) a python object suitable for the context, (2) a string that can be evaluated to such a python object. The latter is needed because matplotlibrc is plain text and we have to parse this. This is quite ugly but works well enough for simple cases.
Markers complicate the situation in that they can both be ints 1 and strings that contain an int "1". I think it is possible to separate the cases - maybe we cannot use the listify approach for that.

Anyway, a solution should make the following modification to the tests pass.

• The first swiches from cycler.cycler() to matplotlib.cycler, which is the validated version.
• The second ensures that matplotlibrc is parsed correctly.

diff --git a/lib/matplotlib/tests/test_cycles.py b/lib/matplotlib/tests/test_cycles.py
index 4fa2616194..587d4f0509 100644
--- a/lib/matplotlib/tests/test_cycles.py
+++ b/lib/matplotlib/tests/test_cycles.py
@@ -29,7 +29,10 @@ def test_marker_cycle():
 
 def test_valid_marker_cycles():
     fig, ax = plt.subplots()
-    ax.set_prop_cycle(cycler(marker=[1, "+", ".", 4]))
+    ax.set_prop_cycle(mpl.cycler(marker=["1", "+", ".", 4]))
+    for _ in range(4):
+        ax.plot(range(10), range(10))
+    assert [l.get_marker() for l in ax.lines] == ["1", "+", ".", 4]
 
 
 def test_marker_cycle_kwargs_arrays_iterators():
diff --git a/lib/matplotlib/tests/test_rcparams.py b/lib/matplotlib/tests/test_rcparams.py
index 096c5cef6c..44be6a9929 100644
--- a/lib/matplotlib/tests/test_rcparams.py
+++ b/lib/matplotlib/tests/test_rcparams.py
@@ -268,6 +268,8 @@ def generate_validator_testcases(valid):
                      ("cycler('c', 'rgb') * cycler('linestyle', ['-', '--'])",
                       (cycler('color', 'rgb') *
                        cycler('linestyle', ['-', '--']))),
+                     ('cycler(marker=["1", 2])',
+                      cycler(marker=["1", 2])),
                      (cycler('ls', ['-', '--']),
                       cycler('linestyle', ['-', '--'])),
                      (cycler(mew=[2, 5]),

That said, a workaround for you would be to use the unvalidated cycler.cycler() (or pyplot.cycler(), which is currently identical #26868).

Prior to #27613 (mpl 3.8.3/3.9.0), it was not possible to specify integer markers (TICKLEFT=1, etc.) in the matplotlibrc file, which uses strings only (or in a cycler, #27596). That PR "fixed" the issue by instead interpreting the string "1" as an integer, but the consequence is that it has now become impossible, instead, to specify string markers whose string shorthand is an integer (this issue).

Given that it is anyways confusing to have two different markers called 1 (tri_down) and "1" (tickleft), that neither of the names is particularly intuitive anyways (IMO...), and that I suspect they are rarely used in practice, I would suggest reverting #27596 and at least deprecating the integer markers and replace them by their full names (i.e. one would have to write plot(..., marker="tickright") instead of plot(..., marker=1)). (More likely, first introduce support for full names, then deprecate the ints in the following release.)

Perhaps we could also deprecate the int-as-str markers (plot(..., marker="1") becoming plot(..., marker="tri_down")) but at least in this case one could have been using shorthand notations such as plot(x, y, "1") so it's maybe reasonable to keep them...

Introducing full names for the markers is a good idea. That makes marker definition unambiguous in every situation. We can separately decide whether we want to deprecate the current forms.

I would not revert anything. AFAICS the before/after of #27613 are just the two choices that a validator can make - convert "2" to int or not. Neither seems better than the other. I therefore would leave it like this. Though I suspect it should be possible to fix this by jumping some extra hoops

• in matplotlibrc (all input is string) bare numbers are converted to integers, quoted numbers become strings.
• in cycler validation we should not convert string to int.
  IMHO the right approach would be to separate conversion from validation. Cycler should only use validation. Although we could discuss whether cycler needs to do validation at all. Using an unvalidated cycler would just blow up later on usage of an inappropriate value.

And also, we should move away from plain-text matplotlibrc. But that's a separate topic.

just the two choices that a validator can make - convert "2" to int or not. Neither seems better than the other.

The point is that I believe that one of the choices (don't convert) is better than the other, for more than one reason:

• String markers are clearly designed to be markers: "1"..."4" are "tripods" with various orientations and "8" is an octagon, positioned at the "natural" center of the shape, so they indeed mark a specific position; int markers are clearly helpers (and indeed used that way in the library) for drawing axis ticks (tickdown, etc.) and arrows at the end of "half-errorbars" using lolims/uplims (caretdownbase, etc.), if used standalone they don't even clearly mark a point because the actual underlying point is actually at one end of the marker (e.g. the relationship between tickdown and the actual position marked on the axis).
• Supporting string markers is consistent with supporting shorthands in plot() (at least plot(x, y, "8") can reasonably be remembered, if you've seen it before). Naturally it's not the same implementation as in matplotlibrc, but from a consistency POV it would be weird if "8" in matplotlibrc and "8" in plot marker shorthand had different meanings.

I appreciate all of the input, especially the patch for tests from @timhoffm.¹

In fact, the reason I found out about this bug was because my mplstyle file was being processed incorrectly. I had traced the issue to validation in matplotlib.rcsetup, though it could be present elsewhere. I believe the core problem is that validation functions are relied upon to coerce values between types. Looking at other validators in matplotlib.rcsetup, most do type conversions as they use _make_type_validator which "validates" by converting the value to the intended type.²

Note that this bug actually affects the following four additional rcParams entries, where _validate_marker is used, and the original cycler bug for axes.prop_cycle:

• "lines.marker"
• "boxplot.flierprops.marker"
• "boxplot.meanprops.marker"
• "scatter.marker"
• The evaluation of cycler("marker", ...) in rcParams and explicit Python code. This uses _validate_markerlist, which wraps _validate_marker.

These rcParams entries all behave differently pre- and post-#27613, as they all use _validate_marker.

I agree with @timhoffm, that it would be better to "[...] separate conversion from validation". However, that may require some re-architecting of how matplotlibrc is loaded and parsed. For example, double-quoting would be a nice way of indicating a string but double-quotes are removed in _rc_params_in_file [1] and their addition may require changing the syntax of maplotlibrc/mplstyle files.

A few notes:

1. cycler(), when loaded from matplotlibrc or an mplstyle file, is handled with validate_cycler, where eval is used to process string values. Therefore, markers passed to cycler() are handled correctly up-until _validate_marker. Integers used to be rejected by _validate_marker, now they are kept but string-integers are converted to integers .
2. The other rcParams entries that use _validate_marker, e.g., "lines.marker", do not use eval(). This means their values are always passed to _validate_marker as strings. Prior to Fix marker validator with cycler (allow mix of classes)  #27613 they were always treated as strings, now string-integers are converted to ints. Given _rc_params_in_file removes quotes, I have been unable to modify my matplotlibrc file to coerce string-integers into string-integers for these RcParams entries.
3. We could allow for str() and int() functions in eval()[2], allowing us to write something akin to axes.prop_cycle: (cycler("marker": [".", str("1"), int(2)]),). Then, we would implement proper type checking in _validate_marker. However, then we wouldn't handle the other RcParams entries properly, which do not use eval(). These would always pass strings to _validate_marker.

It would be great if the following matplotlibrc/mplstyle file was possible.

lines.marker: 2 # int, TICKUP
scatter.marker: '1' # str, tri_down
axes.prop_cycle: (cycler("marker", [".", "1", 2]),) # Cycles through markers point, tri_down, and TICKUP