I have some thoughts on the IL building rules. Currently the spec leaves the IL building rules fully unspecified, allowing clients to decide. While this aims to promote a diversity of IL building rules which can strengthen censorship resistance, I believe there is a risk that many clients could implement similar deterministic rules.
For example many clients could implement a simple order-by-priority fee strategy. If all IL committee members are using the same deterministic ordering strategy then (assuming they have a similar set of transactions in the client txpools) all members would build the same IL. When we take the union we will get an 8KiB IL rather than the theoretical maximum of 128KiB. This undermines censorship resistance, as now a single 8KiB transaction with a high priority fee can censor all other transactions from the mempool. Reducing the amount of overlap between ILs would increase the size of the IL when they are combined, meaning there is more throughput to force-include transactions.
Even if different clients use different ordering rules, it is still possible that we end up with an IL committee all running the same EL client. If these rules are deterministic then we would have the same situation of completely overlapping ILs.
I propose to recommend that implementers should aim for a more disjoint and nondeterministic set of ILs while leaving the exact algorithm unspecified. This can be done by introducing randomness, and using bias to pick some transactions more often than others. This would work by giving each committee member an id from 0 to f; the member with id a would then be more likely to pick transactions with hashes that start with a. Adding bias could further reduce the amount of overlap between ILs while crucially not eliminating it entirely.