Starting with #2, this is all handled by the software. There's nothing a user needs to do to manage the block-level backups and related retention. Even if you are infected, then the only thing that might be affected is the last block-level, but previous ones will remain in place and allow for restores to any point-in-time across those backups. More likely though, the ransomware will cause the full file to be backed up (since the entire file changes) and in that case, previous versions would be flagged for deletion - and this is bad. Easy to fix though - just keep at least 2 versions of files and the previous backup set (full file backup + any block-level backups) would remain in storage. The other thing you should consider is adding a Purge Delay. That way, files that are to be deleted have their deletion delayed a # of days before it actually happens.

Moving on to 3: Yes, it's a good idea and since you keeping files for at least 90 days, you're going to end up with multiple versions for frequently edited files, but what if a file is not changed during that time and 90 days has passed since its backup and the ransomware attack. The whole point of backup is flexibility in restoring. Keeping more than 1 version is ideal.

And now 1: You may lose everything in that case without a purge delay and only keeping one version. if the ransomware changes the file extension *file is renamd)e, the old file is considered deleted and the software may remove the deleted file if you don't have versions and / or a purge delay (or both) in place. If the ransomware simply encrypts the file in place without a rename, you have effectively created a new version and the old one could be removed depending on when the last backup of that file took place. So add versions and a purge delay.