Truecrypt has a deniable encryption functionality, but it's limited to one hidden drive, so a sufficiently determined criminal will just try to extort another encryption key out of you. I want to work on a coding project this summer, and adding true deniable encryption to a truecrypt fork could be worth spending a summer on.
So here's the idea:
When you make a deniable encryption partition, the partition is split into several small pieces (about 10 MB in size). Then you are told it's split into n pieces (256 should be good for an n), and are asked how to distribute the pieces over the logical partitions. Maybe you hand 180 pieces to your windows 8 partition, 30 to a backup partition, 10 to your financial information, 20 for your pirated games, and 16 to your bitcoin stash. Anyway, then the program goes to write info to the first n pieces after asking for the passwords you want for the drives. These first pieces contain information indicating a recognizable header, the partitions, the order to read them in, and information about how to read the corresponding pieces, encrypted.
Later when the program goes back to read the drive, it asks for a password. Since all the information needed to read the drive is encrypted in the header pieces, it goes and uses that password to try to decrypt the first n pieces. The ones which are recognizable after this step are processed, and their corresponding pieces are off to be read. For any starting piece m, the data associated with piece m is only written to pieces with number that is congruent mod n.
Since each logical partition doesn't know about any other logical partition, you can hide the existence of an encrypted partition by making additional partitions that are basically one of the ones you've already made, but given some more pieces that correspond to the hidden OS (Like you could have a volume that's the windows 8 partition, but handed the space of the financial and bitcoin volumes), and hoping that the attacker doesn't like pirating 4K movies off of bittorrent or something that would end up overwriting the hidden volumes. That's the best that can be done, since protecting them would necessarily imply letting the decoy OS know about them.
Sounds simple, but I don't know if I bit off a golf ball-sized piece or a baseball-sized piece, so I will ask for others to help. Sounds good?