One aspect that has not yet been covered is "composition", or combination of values to create a new value.

With LFSR-based CRCs, the logic is completely "linear" so you can combine one checksum with another. For example, you combine the checksums of multiple blocks and create a new checksum for the concatenated blocks, as long as you know their lengths.

OTOH PEAC is not totally linear because of the 1/2 chance to increment the sum so such an operation is far from trivial, to the point where everything must be re-computed from scratch. This can be a problem because some people may want to do the same as with CRC32, however in practice it is rarely used or beneficial, except for one application : tampering with data.

And here, PEAC is not as straightforward as CRCs. It's not impossible either but if you ignore the start of the stream/file, then you have no way to forge the appropriate data. After a few bytes or words, the complexity increases. For each 4 bytes, the sums are incremented, but this is only statistics. But each increment gets blown out of proportion at the rate of phi and this further scrambles the result, in non-linear ways.

Oh, it's a tiny disturbance at first and you can still alter most of a PEAC16×2 checksum by inputting 2 words (4 bytes, plus another word if you want to alter the carry bit) but by the time you have a few words, the avalanche has already started through the carry chains. It takes about 24 words for the avalanche to amplify one bit to a full word. It starts easy so the only practical applications would be limited to only a few altered words.

A pure "Pisano" checksum where the carry is lost would not have this "problem", as it is pretty linear, just compute the checksum of the block you want to replace, then compute the checksum of the forged block, compute some kind of difference and you're done (in theory). But PEAC is not that obvious because of the avalanche of the carries.

So composition of blocks is not easy, but not impossible : it is better to just recompute everything. In practice though, checksums should be regularly spread in a stream to avoid losing too much data when a block is altered, which in turns limits the effort of forgeries.

Some serious math is needed at this point, stay tuned.