Closely related but separate issue:

After being sent to https://twitter.com/oauth/authorize, if the user then clicks the
"Sign Out" link, she is redirected back to /oauth/authorize, but the value of
oauth_access_type gets lost.   The text on the authorization page (vis a vis "access
your data" or "access and update your data") will now reflect the application's
default access type, rather than the access type requested by the original
oauth_access_type parameter.

The text difference based on oauth_access_type is expected. I'll look into why that's not also being applied to the 
token in the end. Do you have a URL I can use to reproduce the problem?

I didn't have a public test page for the bug, but I've just whipped one together.

  http://dairiki.test.discnw.org/twitter/oauth/test.html

The page will allow you to authorize to the "Jeff's Test ALE" application (registered
to @dairiki (me).)   

The page allows you to authorize for either read-only or read/write access,
however the access tokens actually granted seem to always be for read/write access
(which is the default access type for "Jeff's Test ALE".)

Another quirk I just noticed.

1. I visit http://twitter.com/account/connections and revoke access for my app.

2. Using the above test page I get a new access token.  (The token is indeed
   different.)

3. Go back to http://twitter.com/account/connections, my app is listed there again.

4. Here's the bug: it says "approved on 6:19 PM yesterday".  Actually it was
   approved at 6:19PM *today*.  I've reproduced this behavior several times
   over the last few minutes.   I hadn't noticed it before then (but that doesn't
   mean much.)

(If you want me to file a separate bug report for this --- and/or the bug
noted in comment #1 above --- let me know.)

As always... thanks for looking into this!

dairiki: Please file a separate bug for the date issue. Some other things to note in the bug report:

1. What time zone are you in?
2. Do you see incorrect dates on other twitter pages as well, or just the connections page?
3. Do you still see the issue, and if not what time of day was it when you originally saw it?
4. What twitter account was this for?

I've just reported the date issue in this ticket:

  http://code.google.com/p/twitter-api/issues/detail?id=777

I found the root cause and I'm working on a fix now. The oauth_access_type parameter is getting dropped for 
logged in users approving new applications.

A fix for this was deployed yesterday and verified with http://dairiki.test.discnw.org/twitter/oauth/test.html

Thank you for the quick fix!

The issue reported in Comment 1 (above) is still not fixed.   Should I file a
separate ticket for that?

Also, now that I can get read-only access tokens for my read/write app, another issue
has come up.   If I get a read-only token and then later request a read/write token,
I get back the original token and it's still read-only.   I would think that either:

  1. I should get a new read/write token, or

  2. I get the old token back, but if so I expect it to have been upgraded to
     allow read/write access.

(Again, let me know if I should file a separate ticket for this.)

Thanks again!

Please file new tickets for each issue separately. I'll likely work on them at the same time but it's possible I'll also 
need to split the work with someone.