As Tim mentions, in beta two we don't support any form of forward references using StaticResource.  We've been tightening this down for a couple CTP's now, but the last case we fixed in beta two took awhile because it's wrapped up in a larger issue.

Prior to Beta 2, you could have a forward reference inside a Resources section:

<Something>
    <Something.Resources>
        <Object1 x:Key="1" SomeProperty ="{StaticResource ForwardReference}"/>
        <Object2 x:Key="ForwardReference"/>
    </Something.Resources>

Why did that work if other forward references didn't?  Well, actually it didn't always work -- it only worked if you compiled your xaml.  Because in compiled xaml, resources are "deferred content" -- we don't create a resource until you use it.  And so we didn't perform the StaticResource lookup until someone created resource 1, by which time the whole resources dictionary had been loaded and so the object named ForwardReference was available.

Deferred content is a neat optimization, but if not done very carefully, it creates some very weird name lookup behavior.  We already touched on how compiled xaml behaved differently from uncompiled xaml.  But the one that really started driving us nuts is what happens if you modified the resource dictionary before you ask for resource 1?  Prior to beta two, inside deferred content StaticResource lookup was not lexical -- you couldn't figure out the meaning of the xaml just by looking at it, the meaning of names potentially changed as the program ran.  That's fine for DynamicResource -- that's what makes it dynamic -- but it went against everything that StaticResource was meant to be.  So we fixed that -- we still have the deferred content optimization, but we now pre-compute the name lookup as the xaml is first loaded -- and so, StaticResource is now the lexical construct it was meant to be.

Who says programming language design doesn't come in handy?