At first sight, I liked this idea, but this feels economically a suboptimal solution after deeply reflecting on it. I mean, essentially, it’s requiring burning money and we should think about alternative solutions that do not require it (money should be considered a scarce and valuable source). Also, depending on the implementation you could have the following use case (from this audit report):
For example, if an early user put forth the minimum initial deposit and then the rest of the queue held dust amounts, the same user could withdraw far below the minimum initial deposit amount in the next round and the vault would be back in a vulnerable state. Consider taking steps to ensure the supply of vault shares does not go below the minimum initial deposit amount. One way to do this would be for the Pods Finance team to contribute their own initial deposit to the vault that they can guarantee will not be withdrawn.
So it requires first money as well as a certain trust into the first depositor. Generally, as you already have pointed out, I see the use-case specifics, but the initial minimum deposit strategy can also be considered as use-case specific. So I feel the OP’s solution is more use-case agnostic, but the minimum initial token deposit strategy is “simpler”, complies with the EIP4626’s Security section, and can be an optimal implementation for certain projects who are willing to commit the funds and which you trust.