The list of modules you see in a 6.1 installation only depends on the modules that your OpenERP system can find in the various directories where it is configured to look for. These directories are commonly called the "addons path" and are usually passed to the openerp-server startup script via a parameter that looks like --addons-path=/path/to/addons,/path/to/otheraddons
This parameter can also be set in a configuration file with a parameter named `addons_path``

When you use the Update Module List menu, OpenERP re-scans "your addons path" entries and updates the list of modules with whatever valid modules it finds, updating the details of existing modules and adding any new ones. A valid module is a module that has a valid __openerp__.py manifest file and is not marked with installable: False.

Based on this you should be able to understand the number of modules you see in your various OpenERP deployments: it all boils down to the contents of your addons directories. It entails from the above that updating your module list will never automatically discover any new modules or any new updates, unless something/someone has modified the contents of your addons directories.

Warning: this is quite different in OpenERP 7.0, this explanation is for OpenERP 6.1 and earlier version only!

Update: if you're using zipped modules, e.g. for 6.0 or earlier (or on a modified 6.1), you should be aware that zipped modules are considered just the same as module directories if they're found within your "addons path". If you use the Import Module menu the imported modules will be stored as zips in your local addons paths. Depending on the version you're using, any zip with the same name as a module directory may take precedence over the unzipped module (e.g. foo.zip vs foo directory), so it's not a good idea to keep both.

Update 2: to answer your extra questions:

1. It will probably work in any order. However to be 100% correct you should normally update them all at once, or at least update all modules that depend on each other at the same time. If module B depends on A, using a newer version of A could theoretically break B. Conversely, if the newer version of B expects the newer version of A, updating B without updating A could break the system. This is however rather unlikely, as within a stable series the API of modules is supposed to be frozen, so a module should not change significantly enough to break any module that depends on it.
   Well, you asked for it ;-)

2. The easiest place for finding zipped modules is on OpenERP Apps, by looking at the available downloads for your modules and series (6.1).

3. Yes, the OpenERP release policy explains this. Major versions (aka Series) are represented by the first two numbers in the version (i.e. 6.0, 6.1, 7.0). As long as you stay within the same series you can upgrade without much risk, so 6.1.x is compatible with 6.1.

4. Using Import Module is really not recommended for updating modules. You should really try to manage your module source code on the filesystem directly rather than using the interface. If you ever break the interface by installing a module that's incompatible you'll be glad you understand how to undo that on the filesystem and how to remove/reinstall it.
   After updating the modules on the filesystem you should usually start OpenERP once with the -d <DB> -u all command-line options (replace <DB> with your database name) to force a synchronization of all the modules with the source code you've just installed.

5. Not sure what you mean here. The OpenERP database structure is automatically maintained by the system, and it must never change if you stay within the same series anyway (that would break compatibility and requires a new major version)

Warning 2: Having lots of modules available in your installation is not a good objective, and may in fact be rather harmful if you start to install many modules. You should only ever install modules that you really need and that your understand. Before OpenERP 7.0 uninstalling a module was very experimental and likely to break stuff, so it's definitely not a good idea to install random things on a production database (at least make a backup before installing).
Similarly, updating your modules to the latest version is not necessarily a good idea unless you're blocked by a bug you know to be fixed in the latest version. The risks of breaking your system are high if you don't know exactly what you're doing, so it's usually not worth it.