Manual Testing - Selenium Remote Control

(some of this could be automated, most of it deserves some manual eyeballs before release)

Distribution: Make sure the dist zip can be extracted and that none of the jars are empty. (This happens more often than you'd think.) You can find the official distribution in http://maven.openqa.org/org/openqa/selenium/selenium-remote-control/ ... look for the directory named after the current version, then look for the last "-dist.zip" in that directory.
Generated documentation (javadoc and its equivs for ruby/py etc): Is the formatting correct on the automated documentation? Make sure the "Element Locators" section is clearly visible near the top and that it looks OK for Selenium.html (or Testing_Selenium for PHP, or equiv). Also check the "select" command (or method or equiv), which has a pretty complex description; spot check a few others ("selectWindow").
Self Tests on all browsers: Run the Self Tests on Windows, OSX, and Linux. The self tests are really mostly a test of the browser launchers and Selenium Core.
Selenese from the command line: Try running the Selenese tests from the command line, ideally using a test that you just recorded from Selenium IDE. Make sure this test doesn't use any of our checked in test HTML files (TestOpen, etc.) because we often see bugs where only those files work in Selenese mode. Instead, make it a test of Yahoo or something. Make sure you try this once with a "regular" browser launcher and then again with an experimental proxyless launcher like *iehta.
Selenese Ant task: Write an Ant task to run the command line test you just ran. Also, upgrade Selenium Core to the newest version of the <selenese> Ant task; see if that works on all browsers.
SSL: Run SSLWellsFargoTest on Windows. Run it in singleWindow mode (the default), then again in multiWindow mode, then again in PI mode. (We don't run this as part of the build because it tests an external web site.) It covers testing *chrome and *iehta in SSL, unlike the simpler SSLOpenTest.
Browser side logging: Turn on browser side logs to make sure they work properly (nothing breaks & you actually see logs) in every browser launcher. Logging often fails in SSL mode, so try it with SSLWellsFargoTest, too.
avoidProxy: The avoid proxy setting is normally invisible to the end user. You'll need to use a network trace tool to see if it's working properly. (TODO: Explain how)
Browser session reuse. -browserSessionReuse command line arg. (Can we make an automated test?)
ensureCleanSession. Run CacheBlockTest with ensureCleanSession enabled, on various browsers. (On some browsers it only passes with ensureCleanSession enabled.) Make sure that ensureCleanSession doesn't blow away your cookies or anything crazy like that.
Command line arguments. Try every command line argument. (Can we automate this?)