The "modifiers" nonunique and ordered are NOT inherited by redefinitions or subsettings (unlike others aspects of the closely related effective multiplicity). Therefore, if you have a nonunique feature and redefine it you MUST again provide nonunique in the redefinition declaration, otherwise it will revert to the default for Feature::isUnique which is true.
In the example above, uniqueOops redefines the nonunique repeatRef but does not include nonunique again in the redefinition declaration, so it takes the default isUnique=true, and thus the assigned feature values with repeats (a1, a2, a1, a3, a3) are invalid (although the Cameo 2026xR1 validation engine and SysMLv2 Evaluation Plugin don't seem to report it as invalid yet).
BTW: The informal term "modifier" does not appear formally in either the KerML1.0 or SysML2.0 specifications (but is offered as a tool display feature in Cameo 2026xR1 although it doesn't seem to do anything yet).
If you wondered why the redefined feature was named repeatRef it is to emphasise the following related matter:
Webel does the detailed do's and don'ts SysMLv2 analysis for you and provides clear modelling solutions that work!
To learn SysMLv2 with easy-to-follow, fully worked examples attend a Webel SysMLv2 Workshop Seminar group course or learn at your own pace with the Webel SysMLv2 Online course with self-test Quizzes: