Not sure if this is worth even worth a mention, but I was playing around with fragmented backups to test and found something.
I figured I would try to make a backup with a mix of everything. First paper, w/o secureprint, then paper w secureprint, then file w/o secureprint and finally file with securerint. As this was only a test, I didn't take a very close look other than seeing the wallet name (obviously) and the secureprint code staying the same after toggling the latter on/off. After saving and printing the backups, I deleted the wallet and tried to restore them. When I did, the message "If any of the fragments require a SecurePrint code, you will only have to enter it once" (emphasis mine) made me confident the mix would not be a problem.
When I realized none of the backups fragment matched what was stated on the paper/file I realized something was wrong and went back to create a new one. Toggling secureprint on/off shows that this creates a completely new set. However, 3/4 fragmented backups I made have the same fragment-ID (not the 4th), and all 4 obviously the same wallet ID (this was with 0.96.3).
This was just me playing around, and I would have been a lot more careful before depositing anything. Still, there could perhaps be a warning that:
1. you can't mix and match secureprint
2. each time you toggle on/off you create a new set of fragments.
With 0.96.3.99, none of the fragments got the same ID, but the SecurePrint code stayed the same through each toggle.
Based on the initial text of the previous SSS being deterministic, I'm guessing this wasn't a problem before this fix was made?
I see what you mean, toggling secureprint cycles the fragments. I'll look into it.
