This crashes when a notification is received if the regex is malformed. It should catch PatternSyntaxException as you did for require/ignore and I would suggest falling back to Pattern.quote. I would also suggest, in all 3 options, validating the regex and showing an error (toast is fine) if it's malformed before allowing the user to save it.

I think we want (?i) or RegexOption.IGNORE_CASE here for consistency with the standard string and ignore/require regex, and since the description says it's case insensitive. Alternatively, update the description to indicate that the regex is case sensitive.

I think that regex should be always case-sensitive. I added this in strings.
I am not sure how to implement the toast thing, but I fixed the crash

I agree, case sensitive allows for more flexibility and I'm sure anyone who wants to use regex would appreciate it.
Unfortunately, it would appear you forgot to update the code in both places when you changed the strings to say case sensitive.

To post a toast:

CoroutineScope(Dispatchers.Main).launch {
	Toast.makeText(appContext, R.string.malformed_regex, Toast.LENGTH_LONG).show()
}

I agree, case sensitive allows for more flexibility and I'm sure anyone who wants to use regex would appreciate it.
Unfortunately, it would appear you forgot to update the code in both places when you changed the strings to say case sensitive.

To post a toast:

CoroutineScope(Dispatchers.Main).launch {
	Toast.makeText(appContext, R.string.malformed_regex, Toast.LENGTH_LONG).show()
}

I'm not really a fan of creating local functions like this. I think moving it to the companion object as an extension would be better:

private fun String.containsOrMatchesRegex(it: String): Boolean {
	return if (it.startsWith(Constants.REGEX_PREFIX)) {
		try {
			Regex(it.removePrefix(Constants.REGEX_PREFIX)).containsMatchIn(this)
		} catch (e: PatternSyntaxException) {
			e.printStackTrace()
			CoroutineScope(Dispatchers.Main).launch {
				Toast.makeText(appContext, R.string.malformed_regex, Toast.LENGTH_LONG).show()
			}
			false
		}
	} else contains(it, true)
}

Usage: ttsMsg.containsOrMatchesRegex(it)

Well, local functions are there for a reason - they are releveant only to the code using them. We could just duplicate the code and ditch the function, but I think it is less elegant.

Also, the toast should be only when saving the regex no? There is not reason to put it on the service

I agree, case sensitive allows for more flexibility and I'm sure anyone who wants to use regex would appreciate it.
Unfortunately, it would appear you forgot to update the code in both places when you changed the strings to say case sensitive.

Sorry, but I didn't understand what I forgot, could you please refer me to the file?

Well, local functions are there for a reason - they are releveant only to the code using them. We could just duplicate the code and ditch the function, but I think it is less elegant.

I used to have that mindset of keeping scope as narrow as possible when I was starting out, though Java didn't allow nested methods, which may contribute to why I think it looks so wrong in Kotlin. Narrow scope is important, but there are some subjective exceptions.
Functions serve more purpose than to reduce duplication. They also improve readability by breaking functions into smaller pieces (also important for unit testing) and reducing deeply nested/indented code. Sometimes that's worth expanding the scope of the function into the class.

However, I do sometimes use the cousin of the nested function, the lambda, which I find more visually acceptable especially if it's small.
Just the first 2 lines would change, like so:

val containsOrMatchesRegex = { it: String ->
	if (it.startsWith(Constants.REGEX_PREFIX))
	...

Usage doesn't change.

Anyway, I won't let this block the PR, but I'll eventually change it to match my code style preference if you leave it.

Also, the toast should be only when saving the regex no? There is not reason to put it on the service

Ideally, yes, as I previously suggested.
This is the lazy option which I will also accept. I just want something that could make the user aware that the regex is bad. I would likely move the validation to on-save after the merge if you don't.

Sorry, but I didn't understand what I forgot, could you please refer me to the file?

My mistake on the text replace regex. I saw the (?i) and didn't pay attention to it being for the plain text matching. The ignore/require regex still needs fixed (see other comment on the line).

I believe that everything has it's time and place, and sometimes nested functions might be the best solution, like in this case.
I will change it to lambda.
You are welcome to refactor if you would like, I have no problem with that. I just think that a code refactor should be backed by a good reason, and I don't really see the benefit here.

I will try to move it on save, but I am a bit short on time so if I get stuck I will use the lazy solution.

I saw, thanks

It's just a matter of familiarity. I don't think I've seen anyone use a local function before even though I work with other experienced Kotlin devs and there's plenty of opportunity to do so in those much larger projects, so it looks weird to me. Maybe that's because we all come from a Java background and it's almost never mentioned in Kotlin documentation and examples. I haven't given it much thought until now, so I'm looking around for other perspectives from the larger Kotlin community and I may change my mind. Feel free to leave it a local function if you prefer.

On the other hand, Kotlin allows functions and properties at the file level outside of any class, again unlike Java. It felt wrong at first, but thanks to how common it is for Compose, I've gotten used to it.

I actually come from a c# background, I don't really know Kotlin 😄

I rarely use local functions aswell, but on some occasions they are helpful.

Need to remove RegexOption.IGNORE_CASE here to make the regex case sensitive.

Well, local functions are there for a reason - they are releveant only to the code using them. We could just duplicate the code and ditch the function, but I think it is less elegant.

I used to have that mindset of keeping scope as narrow as possible when I was starting out, though Java didn't allow nested methods, which may contribute to why I think it looks so wrong in Kotlin. Narrow scope is important, but there are some subjective exceptions.
Functions serve more purpose than to reduce duplication. They also improve readability by breaking functions into smaller pieces (also important for unit testing) and reducing deeply nested/indented code. Sometimes that's worth expanding the scope of the function into the class.

However, I do sometimes use the cousin of the nested function, the lambda, which I find more visually acceptable especially if it's small.
Just the first 2 lines would change, like so:

val containsOrMatchesRegex = { it: String ->
	if (it.startsWith(Constants.REGEX_PREFIX))
	...

Usage doesn't change.

Anyway, I won't let this block the PR, but I'll eventually change it to match my code style preference if you leave it.

Also, the toast should be only when saving the regex no? There is not reason to put it on the service

Ideally, yes, as I previously suggested.
This is the lazy option which I will also accept. I just want something that could make the user aware that the regex is bad. I would likely move the validation to on-save after the merge if you don't.

Sorry, but I didn't understand what I forgot, could you please refer me to the file?

My mistake on the text replace regex. I saw the (?i) and didn't pay attention to it being for the plain text matching. The ignore/require regex still needs fixed (see other comment on the line).

I think a blank line (\n\n) before the regex part in both strings would look better to separate it from the basic usage instructions.