If you're only concerned about 2.X, then yes, optparse will *never* be removed from 2.X. There will be a deprecation note in the 2.X documentation but deprecation warnings will only be issued when the -3 flag is specified. Please see the "Deprecation of optparse" section of the PEP:
http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse
I do not think that optparse should be deprecated at. It is good at what it does and its limitations make its starting point less confusing for people with different backgrounds that Python.
Compare: http://docs.python.org/library/optparse.html http://argparse.googlecode.com/svn/tags/r101/doc/index.html
argparse should be recommended as advanced and more featured variant of optparse - that goes without saying, but forcing people to switch and annoying them with deprecation messages brings only headache.
As has been noted already nobody is forcing people to switch. Optparse will be available as a separate package and everybody will be free to install it and will not have any deprecation messages anywhere.
Just like optparse is better getopt, the latter could also be useful for people coming from other languages and porting their libraries to Python.
I would better concentrate on real code examples how argparse solves problems and would really want to see http://www.python.org/dev/peps/pep-0389/#out-of-scope-various-feature-reques... implemented until argparse enters phase where backward incompatible changes in API are impossible.
I would prefer to see PEP 389 as a document describing proposed solutions to argument parsing problems rather than petition to replace one library with another. So, it should display common argument parsing scenarios (use cases) with examples that are also useful recipes for documentation. I guess more than 90% people here doesn't have time to read argparse methods descriptions to see what they could be useful for.
-- Psss, psss, put it down! - http://www.cafepress.com/putitdown