I think for the intro, it may be better to start with the problem formulation, and then go on to talk about the algorithm. E.g. as follows:

Consider the following problem: You are given a length $n$ text, and a length $m \leq n$ pattern to find in the text. You need to find all occurences of the pattern in the text in $\Theta(m+n) = \Theta(n)$ expected time.

The algorithm described below was authored by Rabin and Karp in 1987 and is based on the concept of [string hashing](string-hashing.md).

We should also write that here randomization affects the correctness of the algorithm, rather than its execution time, hence there should be analysis of collision probabilities.

I don't think the randomization affects the correctness if you check the hash collisions. If you ignore them then yes.

If the task is to find all occurrences of the pattern in the text, you can't check them all, it would lead to worst-time $O(nm)$ even with a perfect hash function. The current implementation and the task statement heavily imply that we just report all hash coincidences as a match.

I reported the worst-case time too. I do not think we should compromise the correctness because of the worst-case time which should be rare. Sleator goes over both options so maybe both should be mentioned.

Checking occurrences is somewhat fine if you only want to check that whether the pattern occurs at all (and possibly report one specific match). We can suggest doing a full match check in this specific case, but then should also provide some bounds on the probability that the number of false matches is high.

For the formulation of finding all matches though we shouldn't assume that the number of valid matches is low at all, this is just a kind of assumptions that will be wrong in competitive programming context with a reasonably well-prepared test set.

In the worst case of a hash collision every time, the performance degrades to $\Theta(nm)$.

It doesn't, hash collisions only lead to false matches.

Besides, we should add:

1. What should be randomized (either $p$ or $x$ should do) and how;
2. What is the expected probability of a false match due to hash collision.

But I'm generally not sure whether it should be covered right here, or in the general hashing article (in which case this paragraph should link to a corresponding paragraph).

The way it is presented usually is that for every hash match we still check for correctness. And the time complexity is in CLRS.

Then it diverges from the provided implementation, and searching for all matches of $a^{n/2}$ in $a^n$ would be quadratic due to the checks for correctness...

Yes, the assumption in CLRS is that the number of valid matches is low. I'm not opposed to rewriting it to assume a hash collision never happens, but I would make that explicit.

I'd say what we need is not the assumption that a collision never happens, but rather a proper estimate on the probability of it happening, so that people can adjust their randomization range and e.g. number of mods or bases to be checked to ensure a probability that they're fine with.

This isn't consistent with the computations in the code snippet, as the code snippet use prefix sums instead of rolling.

I think the rolling is more intuitive and that's how CLRS and Sleator present it. I can make a note saying the code uses prefix sums instead. If I make new code it'll probably be a separate PR.

I think competitive programmers usually already know about prefix sums when they learn hashing, so explanation via prefix sums should be more intuitive, as it refers to a familiar concept, while rolling is, in essence, an ad hoc trick. Prefix sums are also more versatile and practical, as they allow to compare any two substrings without a need to compute hashes of all substrings of the same side, which is what you often need in many generic hash problems (so, they'd need to learn prefix sums approach anyway).

So, mentioning rolling is fine of course, as knowing it broadens the horizons, but I'd also put at least as much emphasis on prefix sums just due to how practical and useful they are in the context of polynomial hashing. The only concern I have here is that it will probably make more sense to have a dedicated section about prefix sums in hashes own article, and link to that from here.

Idk if using prefix sums is even Rabin-Karp any more. Maybe Rabin-Karp can be grouped in with other sliding-window type functions.

To some extent it is, e.g. this refers to prefix sums based approach as a variant of Rabin-Karp. Though it is not popular in literature at all, in competitive programming context, it's common to use "Rabin-Karp algorithm" to refer to the idea of using a polynomial hash for substring matches, rather than to specific rolling hash based variant. This, in turn, was partly popularized by the fact that original e-maxx.ru article took this approach...