(I wanted to get this down before commenting... too much crap going on and i got two ideas while reading partway through your explanation I pasted to a word doc to make more readable =P. sorry about the double post, but I didn't want to relate the last post to this one.)
I just thought of another consideration with method II... to make it more usable, you can have it calculate its first value however long it takes, but from then on whenever it gets an invalid variable, it chooses whatever variable was last, or possibly some simple change to it. The idea is to store several random variables, so when the thing takes longer than usual, you have a few left to use. Using it would cause it to assign the 2nd var to the first, 3rd to 2nd, and so on. this method may not be what one would consider perfect, but it would always be ready with a result, and would still technically be random, though the same thing is more likely to happen next. Sometimes this might actually enhance gameplay, depending on how it's used, but i think predominantly the method II triggers would work fast enough to keep the randoms coming. you could even assign it an additional +max number (+7 for 0-6) so you can tell when it was defaulting to last value, and that could just be used in emergencies.... otherwise it'd write over it with the next value it gets that is valid. So if => 7, and new var =< 6, then write over.
The only weak time would be at the very start, and if you wanted, you could either have a game start button that would verify the random process is finished, or just have the game start after it, or use a slightly less random but quick version to get things started, if it doesn't matter a whole lot right off, but is needed. You can also use it of course to sway game modes in favor of a more popular one, of course.
Next thing I was thinking about, which is before I finished your tutorial, was using a death counter and some form of randomizing translations of the number. Basically you'd just have it constantly fake randomize it, with equal probable outcomes. This can be as simple as adding 3's to a 0-6 constantly, while modding down to keep it in 0-6. If the randomization is simply whenever the player activates it, it will be sufficiently random based on time: just as motion is one way, so is time. I would be wary of using trigger functions for this time, as they are very precise undoubtedly, or at least mostly, so you'd likely get the same results each game. But throw in a human, and things get random. Throw in some random switches to the translation to determine the number added, and it's basically random. I'm sorry if this is basically your method =P... I stopped reading where you talked about "add one or subtract one" paragraph.
*reads* yeah dang, your death count randomization is basically the same thing. Well at very least, you were the inspiration. Yeah, on finishing, it's essentially exactly the same. yarr... oh well i tried =P. In any case, given a few seconds of time and/or human intervention for randomness, it's all pretty much worked out here, i believe.
None.