Frame Buffer Blending is a "draw order dependent" technique - that is, by definition you will get different results depending on which order you submit your drawing calls.
Typically the only way to achieve the desired results is to render back-to-front; this guarantees that all necessary computations are done in the correct order (e.g. the background is computed before the semi-transparent window).
Sometimes you can "hack" your way around it by disabling Z-Writing and Z-Testing, but that is often a "looks correct" rather than "is correct" approach.
Be careful when using the blend modes with "DESTALPHA" involved - your render target (or back buffer) must have an alpha channel or you'll just get a default value (should be 1.0, but if you're not seeing *anything* then it could well be a 0.0 default).
You could try running a PIX full call-stream capture and then stepping through each/every draw-call and inspecting the frame buffers contents. The latest build of PIX in the June SDK now includes "Pixel History" so you should be able to examine exactly what operations contributed to the final pixel colour. It might not solve your problem, but it should definitely give you some insight into why you're getting the results that you are - and with a bit of experimentation you can try and devise a pipeline configuration that does generate the results you want.
Alternatively, just stick with the original method - its what most people do!
First render all opaque geometry (if you can, render front-to-back to try and make use of early Z rejection) then in a second pass render all blended geometry in back-to-front order. A sometimes useful trick is to render each piece of geometry in two passes - once with D3DCULL_CW (to draw the back faces) and a second time with D3DCULL_CCW (to draw the front faces). This may be overkill depending on what you're doing...