@pichi-42 - A Python track maintainer here. I’m sorry that you feel like this is too much work and discussion for what looks like a small or straightforward contribution. The conversation is not meant as a gate or a challenge to your expertise or effort. It is also not intended to keep you from contributing.
What you may or may not know is that problem specifications, and the test data within it are shared across all 61 programming language tracks. While tracks can choose to opt out of the data, skip cases for an exercise, or in some cases add track-specific cases of their own, its important that we keep the canonical data as small and clean as possible, since every change triggers exercise updates for the programming language tracks that use it.
We also try to keep the data as generic as we can, and only add test cases that are significant for a wide swath of tracks or approaches. That means we debate and discuss a lot more, and for more reasons than we do when considering track-specific updates. We also accept way fewer PRs and at a slower pace, because at least three maintainers (and often more than that) have to form a consensus around the proposed changes.
@IsaacG is weighing in from his perspective, as will other track maintainers as they have time and interest. He may sound super-critical to you - but he really does want to understand if what is being proposed will benefit a wide range of programming language tracks and student solutions.
One of the big issues here is that very few programming languages have regex engines that support recursion in the core of the language. A quick look shows Ruby 2+, Elixr, C, R, Erlang, PHP , Perl, Raku, and those that embed or use PCRE. Python only has access to recursive regex through a third-party library, and we currently don’t allow third party libraries on our track.
So I am rather ambivalent here, since solutions on my track must take the approach that Isaac mentions above in his spoiler tag.
That doesn’t mean your contribution is not wanted. It means that you need to make a case that this would benefit those tracks that have recursive regex, or would be an important track specific add-on for those tracks. The tracks would then decided if the additional test cases were wanted in canonical data or in track addendums.
And that is a lot of work and negotiation. What I might suggest instead is that you consider writing up an approach document (see this post and this one for how those look on the website) for Elixir and Erlang (and any other languages where you have expertise) to point out to students what recursive regex is, what its pitfalls are, and how to test for errors.