How does OpenID delegation work on the Relying Party? Have the specs changed recently?

Consider this scenario. I have my own website, that I use as my identifier, but I use a third-party OpenID provider (in my case yahoo), as described here, to login on Relying Party (RP) websites such stackoverflow and sourceforge.

It seemed to be a wise move:

I am not locked in with an OpenID provider, since if/when yahoo will not offer the service anymore, or will start to charge for it, or I will not trust them anymore, I can switch provider painlessly
I don't have the economic, administrative and security burden of installing and maintaining an OpenID provider on my server

Question

How is the RP supposed to work? My understanding is that it should use the identifier I provide, and use the provider (yahoo) only for authentication (and not for identification). Is that correct? Did something change recently? Just to be clear, I mean that my identification should be

http://www.mysite.com/myPreferredUrl

and not

https://me.yahoo.com/myYahooId (which is where my website "redirect" the authentication as described in the above website)

Side note

I'm asking this question also because things seems to be broken right now (they were ok few months ago). If I try to login on stackoverflow, I write the mysite.com URL, I am correctly "redirected" to the yahoo website, on which I log in, it asks me if I'd like to "continue on stackoverflow", I say yes, it "redirects" and on the stackoverflow site I see "This is an OpenID we haven't seen before", it shows my yahoo ID and I'm actually locked out!

Is it a bug, or am I missing something?

PS: if you are wondering how I'm writing this question, this is because on one of the many machines I use, a browser still has a valid cookie....

EDIT: Andrew Arnott's answer below suggested a way to fix my problem (i.e. switching to a different provider). But I'm still interested in some details: what has changed from OpenID 1.1 to 2.0, about delegation? Why in the specs it has been choosen to let the provider "break" the delegation? The more you explain, the better the chances to have your answer accepted.

Solution

I believe Andrew's answer is quite accurate. The only thing I can add is a little bit about how the v2.0 spec ended up the way it did, allowing the provider to choose to not work with delegation. I think one of the motivators was the server-directed identity selection, in which the user just supplies "yahoo.com" (or click the Yahoo button), and then their chosen ID comes back from the server in the id_res response. This also allows the server to do things like offer a choice of which ID to send (as Yahoo does) or send a unique identifier to each RP (as Google does).

It also means that all the necessary information is in an id_res response, which means the RP doesn't need to store state from its checkid request in order to process the response. In fact, a provider could send an id_res response directly to the RP without the RP initiating it with a checkid request at all.

A v1.x provider was completely unaware when delegation was evening happening. This design prevented a provider from even choosing to not support delegation, but also made for some UI problems; it would be asking if you wanted to provide the "joe.coolprovider.com" ID when you were actually using your delegated "joesmith.org" ID.

So, there's the tradeoff. Delegation is still possible, so the hope was that users who really want delegation (which, let's face it, is going to be dwarfed by the number of users from these big sites) can choose providers that offer the features they need. (In other words, let the market fight it out.)