Before I’d trust a fork, I’d want an idea of why the original developers considered it insecure in the first place. I’d think if they just didn’t have the resources or interest to maintain it, they’d say they were ceasing to maintain it rather than make an ambiguous statement about security. And there’s more than one security risk. If it were something like they were ordered to hand over copies of the private key used to sign binaries, rendering TrueCrypt vulnerable to government-created “official” versions, that can be dealt with in several ways. If it’s a case of TrueCrypt being unable to protect the data against interception within Windows on it’s way to the application, there’s nothing anyone can do about that and it has to be mitigated against in other ways. And if finally there really is some obscure and fatal flaw in the basic design or coding of TrueCrypt that makes it inherently vulnerable, we’d need to know what it is so we know any new maintainers have in fact fixed it before we could trust the new fork.

I’d note one interesting indirect attack: use methods that’ll cause the most secure projects to declare themselves at risk without letting them say why, letting paranoia push users into switching to software maintained by less scrupulous companies who’ll stay quiet about their software being compromised until forced by outside discovery of the compromise.