I would not want my application to be able to tell if I am logged in or out at the openid provider.

I like the way things work with openid. It's simple, elegant and it works beautifully. I don't want facebook connect/ MS passport like session management. That is exactly what the draw of openid is for me.

I will not leave a comment on your site because you require me to tell facebook, an app provider I don't trust that much, to know how and what I did on your site.

the single logout/login should be done in the browser. One login on launching it, and then all your passwords get automatically filled in by the websites in the question. Logout is done automatically after a custom period of time or closing of the browser.

By browser, do you mean inbuilt capability, or a web application that does this for you? If it's a browser capability, I think you've missed the point - which is that for kiosk situations, I definitely don't trust the machine I'm on.

Even if it's a web application, I don't know that I like giving anybody else my credentials, and especially if it's handled via JavaScript, if I don't trust the machine I'm on, why would I trust it to relay passwords to all my web apps?

I think the OpenID approach makes more sense, but what it currently lacks (in addition to broader appeal) is the ability to logoff centrally. I don't want my PC to act as an intermediary to my credentials, and really, I don't want a third party housing my credentials either... I want a third party to handle authentication by providing a trustworthy identity to an app, and it can handle authorization and beyond within itself.

For the kiosk situation I'd assume the best solution is for the end of a kiosk session to involve a full cookie wipe. If you can't verify that the kiosk does that (or do it yourself), obviously you shouldn't use it.

This is true, and would make me significantly less paranoid about logging in (to wherever) at public terminals.