From zefram@fysh.org

Built-in character classes such as <lower> consistently accept any
diacritics on a matching base character, matching the whole grapheme​:

/^<lower>$/.ACCEPTS("u\x[308]").Bool
True
/^<lower>$/.ACCEPTS("n\x[308]").Bool
True

Matching against a literal character or a <[abc]>-type enumerated
character class consistently rejects any diacritics on a matching base
character​:

/^<[nu]>$/.ACCEPTS("u\x[308]").Bool
False
/^<[nu]>$/.ACCEPTS("n\x[308]").Bool
False

But a <[a..z]>-type range-based character class has inconsistent
behaviour​:

/^<[a..z]>$/.ACCEPTS("u\x[308]").Bool
False
/^<[a..z]>$/.ACCEPTS("n\x[308]").Bool
True

The behaviour seems to be that if in NFC the first character of the
grapheme is the unadorned base character then it accepts, but if it's a
combined character then it rejects. This dependence on the representation
breaks the grapheme view of the string, and so is presumably a bug.

I think a <[a..z]>-type range should, with respect to diacritics, behave
either like <lower> or like <[abc]>. I am unable to discern which
is really intended; none of the documentation that I've seen addresses
grapheme semantics. I note that matching a specified base character with
arbitrary diacritics is a meaningful facility, and given that <lower>
et al have that behaviour it should probably be available somewhere.
The character range feature is almost providing it, but it's obviously
not been designed to, because a single-character range such as <[n..n]>
is rejected.

-zefram

From @smls

I note that matching a specified base character with
arbitrary diacritics is a meaningful facility, and given that <lower>
et al have that behaviour it should probably be available somewhere.

This facility is already available in the form of the :ignoremark flag (or :m for short).

I'm pretty sure that <[a..c]> should match exactly the same thing as <[abc]>, and that ("b\x[308]" ~~ /<[a..c]>/) matching is a bug.

The RT System itself - Status changed from 'new' to 'open'

From @TimToady

The code generator in nqp for char ranges was incorrectly using ordat and ordfirst to find the character to compare, which throw away information on synthetic characters. We now use the getcp_s instruction instead, which leaves synthetics negative, so that they drop out of the character range correctly (but only when :m is not specified, of course).

nqp fix in 2df0a0656e4b20a72bd73e6d2b6214b584d095ac

rakudo bump in fe90be01c6546e1dbb2ee7ff794e8b6ea1491268

Tests updated in 172f6945653ddbce944af1d7cae9ad956f3a70b9

@TimToady - Status changed from 'open' to 'resolved'