You have some misconceptions about metastability
1) You talk about AFTER the metastability period.
The whole point is that, although you can scope the waveform after the event, and figure out when things ended, the circuit, trying to do the decision job, at the time, has no way to 'observe' the whole waveform, it cannot look into the future. Circuits that try to overcome metastability by determining when it has ended, suffer from metastability in the 'has it ended' decision block.
2) You talk about the 'desired' result being '1'.
Metastability only occurs when the correct result could be 1, could be 0, dosen't matter which, but has to be solidly one or the other.
For instance, an asynchronous interrupt arrives at a processor with a different clock to the one generating the interrupt. It doesn't matter whether the interrupt processes this cycle, or next cycle, as long as it does one or the other.
If it is important that the interrupt processes this cycle, then your interrupt has to meet the setup for the processor interrupt with respect to its clock. If it doesn't, you have a system design problem, not a metastability problem.
Metastability resolves itself exponentially. If the likelyhood of still being metastable after 1nS is (say) 1e-6, then after 2nS it will be 1e-12, and after 10nS it will be 1e-60. You will notice that this last probability is still not zero, but you are unlikely to see it in your lieftime, or indeed the age of the universe. If you did, you would be hard-pushed to repeat it!
So, if you wait long enough, metastability becomes too small a problem to be a practical problem. You MUST allow enough latency for that decision to be made.
But you may not wan to run your system clock slow enough. Pipelining! Just like you do with slow multipliers or execution control units. Spread the operation out over several serial execution units and run your clock quickly. The process 'wait' is just a D flop. Use a string of two or more D flops until you have waited the requisite time to reduce the effect of metastability to 'unlikely in the age of the universe'.
There are two ways to send a d-flop metastable. The first is by violating the setup/hold input timing requirements. The second is by violating the logic levels. The first will typically happen when an event generated in a different clock domain arrives at a clocked input, the first flip flop of a synchroniser. As the clock domains are different, here is no guarrantee that timing requirements will be met, and a fast data edge can occur at the same time as the clock signal. The second will typically happen between the first and second flops in a synchrnoiser, if the first flop has been sent metastable, and is generating an intermediate logic level out. This may be read as 0 or 1 by the following flop, or may send that metastable as well.
Think of a synchroniser as being asked to make a decision of whether the 0 to 1 data transition occurred first, or the clock. If the clock, the output is 0. If the data transition, the output is 1. A d-flop that is in the process of latching is an amplifier, with positive feedback. As an amplifier, made from real transistors, it has a bandwidth. You can see what happens to the setup and hold times in a datasheet for cmos d-flops as the supply voltage changes, and as a result their bandwidth changes. Larger bandwidth can resolve smaller setup and hold times. But, as the data edge approaches, and then crosses through the timing of the clock edge, the time difference becomes infinitessimal, and so the bandwidth required to make the decision becomes infinite. You cannot have an infinite bandwidth amplifier, and a finite bandwidth amplifier cannot guarantee to make the decision in any finite time. Metastability. But the longer you wait, the exponentially more likely it is to have made a decision. But not guaranteed.
