I feel like the main substantial difference between this proposal and mine is that your proposal has fluid shuffling (ie. one validator is reshuffled at a time) and mine reshuffles in discrete periods, so that’s the best thing to focus on.
First of all, reshuffling notaries fluidly makes it harder to cleanly implement my strategy for cross-link inclusion, which specifies that within each epoch (which is coincidentally a Casper FFG epoch) every validator can participate exactly once, and is assigned to exactly one shard during that epoch. With this approach, you could have weird situations where a cross-link for shard A is added at the start of an epoch, but then later on the cross-link for shard B cannot be added because the validators for shard A all went to shard B. A validator inducted near the end of an epoch would not be able to participate in a cross-link, because they would not have enough time to verify everything in that shard.
Second, the formulas for calculating shard assignment seem like they would be more complex. I suppose you could do it by storing the shard assignment in the state, permanently assigning each validator to a slice (0 <= k <= epoch\_length) and then storing a separate shuffle parameters for each slice and reshuffling slice k in every block k mod epoch\_length; that said, it’s still slightly more annoying.
I suppose one thing you can do to solve the first problem is to redesign the mechanism somewhat, for example so that in every epoch the system only accepts cross-link signatures made at a very specific height. But I’d need to think more about how to accomplish this.
Gradually reshuffling proposers is something I’m fully onboard with already.