Yes, and with more regex engines: https://github.com/BurntSushi/rebar/blob/177f5d55e916964b9c4...

Beyond what's in the OP, that includes RE2, Hyperscan, D's std.regex, ICU, Perl, Python's third party `regex` package, and `regress`.

https://go.dev/play/p/Tce1qWjfjOy matches their results.

I've also run that locally against "go1.22.1 darwin/arm64", "go1.21.5 windows/amd64", and "go1.21.0 linux/amd64" with the same result.

I've now tested C#, directly, and got the same result as the article. It also documents the behavior:

> The ^ and $ language elements indicate the beginning and end of the input string. The end of the input string can be a trailing newline \n character.

I fail to add carriage return to the test string on that site. Which I guess would be an issue on Windows.

>Newlines at the end of a string are certainly something that could get lost in transit inside an online service involving multiple runtimes.

In what way could newlines at the end of a string "could get lost in transit"?

If you write it to a text file by itself and then read it from that text file, each runtime can have a different definition of whether a newline at the end of the file is meaningful or not. Under POSIX, a newline should always be present at the end of a non-empty text file and is not meaningful; not everyone agrees or is aware.

There are plenty of other ways, too; bugs happen.

Ideally no runtime should alter strings passing through ("in transit") from one runtime to another - unless it does some processing on them.