One of the working principles of the scrambler is that it should be able to work, or at least recover by itself, in catastrophic situations, such as when one of the "sources of entropy" is dysfunctional. These sources are:

1. D, the input data, which is not at all under the system's control. Expect it to be lousy, though my dual-stage random() if nifty.
2. S, the shift register/LFSR : so far I have implemented a degenerate/minimalist/barely sufficient LFSR8 to bootstrap the design and test its limits.
3. FG (merging 2 bytes from 2 LUT entries) mixes D then affects R. The eventual carry spills over the new FG (out of the barrel shifter) and gets recycled for the next cycle. That's the red loop below:

This loops is important to supplement the deterministic sequence of the LFSR, which is obviously predictible, but it's only here to "kick" things enough to get the entropy to increase. From there, the LUT gets scrambled even more and FG can have more entropy in return. So the "red loop" of FG needs a careful design. For now, FG is the MSB of the output of the barrel shifter, plus some carry-in from R. It's not much and I don't know if more is required, but FG "leaks" to R in the second cycle, after addition to the LSB of the barrel shifter.

So R depends on 4 somewhat independent table lookups and 2 previous values of D. Reconstructing the full equation for the value of R ends up with having to know D and the barrel shifter's output. But the latter depends only on the LFSR which remains independent, unaffected by other data, and can't leak directly or easily. So all one has to do is "prime" the filter with a random state of the LFSR. The thing is : there are 1+8+5=14 bits consumed by the pipeline, only 16K combinations to consider. A LFSR32 will provide a longer sequence of these 16K substates but it was not meant as a strong protection either, but a tool to ensure that the LUT's entropy would always increase. The "non-leaking" part, or decorrelation, is just a bonus.

BTW it's "decorrelated" because there is no way to reconstruct the LFSR's state from R, which also means I should remove the 1-bit carry-in link. Now I must find a different source for them, maybe implement some sort of PEAC with it ?

Anyway now the diagram should be clearer, with the decorrelated LFSR path at the bottom, and the "FG loop" at the top.