The version number in for the SF references within the web.config is all you will have to change to switch to version 1.6. The PublicKeyToken stayed the same and won't be changing.
FYI: The PublicKeyToken is a hash that is computed for the assembly when it is signed (strong-named) to allow it to be put into the GAC. The value of the token is determined by the .snk or pfx (public/private key pair) you use to sign the assembly. So, if you use the same .snk to sign multiple assemblies, they will all have the same PublicKeyToken. We aren't going to change the .snk file that we use for SF, so it will stay the same from version to version. If you ever need to know the PKT of a file: in Vista you can view it's properties in Windows Explorer and the Version tab will tell you the value and in other OS's you can drop it in the GAC and then view it's properties.
There might also be some other places in the web.config and pages where the SFWeb prefix is registered (usually at the bottom of the web.config) that will also need to be changed from 1.5 to 1.6.
#2 Yes, 1.5 can run along 1.6 on the same server. In fact, different versions of 1.6 can run along side each other on the same server. If the version # of the DLLs are different, then you can put them in the GAC, but if it's a development server and the DLL changes often without a version number change, it's easier to just put the DLLs into the bin\ folder. That's what we do most of the time (we don't use the GAC much any more on web servers).
Also, as a tip, in development, you might want to make your different websites use different app pools in IIS. The app pool contains the AppDomain in .NET which contains the loaded assemblies. So, if 2 websites have different versions of the same DLL (with the same version number) only one of them will get loaded into the app pool.