Fun to read, well written, but I am not a big fan of the "oversampling" based explanation, as you start to think about functions on real values that way, while it is really finite field maths that underpins the working of these codes.
Also, Reed Solomon is not a particularly great forward error correcting code. They are optimal as "erasure codes" (i.e, you can lose some data, but the remaining data cannot have changed), but as error correcting codes, LDPC codes / Turbo codes outperform them a lot: e.g. satellite communication (DVB-S2), hard drive error correction all switched to LDPC's.
I thought Reed-Solomon also worked with a mix of erasures and errors? I wasn't aware of a requirement that erasures can't be corrected in the presence of errors unless you have hit the erasure limit for your chosen code.
This is inherent. A code can only unambiguously correct errors at half the distance of the code.
Visualize a lattice of possible input words: https://people.xiph.org/~greg/temp/lattice.png lets say that we are using a code where the valid codewords (dark dots) are at least 4 moves apart. If you use this code for error correction, you'll take a received word and move to the nearest codeword, but this is only unambiguous if you correct errors at up to half the distance between any two words.
RS codes are optimal in that they achieve the best possible distance for their size (they are MDS codes).
They may not be what you want to use in some applications because of the computational complexity of decoding with errors, or because the application can make use of list decoding which can be more efficiently achieved with other codes, or because they need different sizes in particular, the symbol size constraint with RS is burdensome for many applications.
The symbol size issue is a particular driver for other choices. Say your HDD codes data with 4-bit symbols but to get good performance you want a code that is a whole sector wide. If you use a 10 bit RS code to code in blocks of 10240 bits, then a single 4-bit symbol error potentially corrupts 20 bits of input.
Codes with large input symbols also don't lend themselves well to soft-input. (because instead of propagating around a single 1 or 0 probability you need to propagate around a probability distribution function equal in size to the field). So they're generally much less attractive for noisy channel coding since modems can easily give soft-outputs.
Also, Reed Solomon is not a particularly great forward error correcting code. They are optimal as "erasure codes" (i.e, you can lose some data, but the remaining data cannot have changed), but as error correcting codes, LDPC codes / Turbo codes outperform them a lot: e.g. satellite communication (DVB-S2), hard drive error correction all switched to LDPC's.