Proper order of multi-environment config
In my experience, the order does matter. The array is read in order from top to bottom testing the domain for a match against each criteria (key). If there's a match, that array of settings is used and continues down the list which can possibly overwrite variables that were previously set.

For example, in this configuration...

// Development
'dev.mywebsite.com' =&gt; array(
    'database' =&gt; 'dev_mywebsite',
),
// Production
'mywebsite.com' =&gt; array(
    'database' =&gt; 'prod_mywebsite',
),


Your development site http://dev.mywebsite.com will be matched twice, once with the full url dev.mywebsite.com and second as a partial match for mywebsite.com. The second match will overwrite the database setting and your dev site won't load properly.

The Craft documentation example uses the domain criteria of '.com' and '.dev' with '.com' coming after '.dev'. That works fine because example.com will never partially match example.dev.

The "Foolproof Multi-Environment Config" from Craft Cookbook works by matching specific server name local.domainname.com or stage.domainname.com first and using a the production environment as a fallback.

Similarly, you could use the config order to your advantage and only change settings as they're needed. The '*' array can be used as a default/fallback environment.

For example:

// Default environment: Production
'*' =&gt; array(
    'tablePrefix' =&gt; 'craft',
    'server'   =&gt; 'localhost',
    'user'     =&gt; 'xxxxxxxx',
    'password' =&gt; 'xxxxxxxx',
    'database' =&gt; 'prod_mywebsite',
),
// Development
'dev.' =&gt; array(
    'user'     =&gt; 'xxxxxxxx',
    'password' =&gt; 'xxxxxxxx',
    'database' =&gt; 'dev_mywebsite',
),


Notice this setup doesn't change the server setting since the dev environment also uses localhost.

Also, I've seen setups where the fallback settings are the Development or Local instead of Production. The advantage there is that your Production
site data would be protected from errors in your config file. I've actually made a mistake where the staging server domain didn't match the config file and changes from the staging server were happening to the Production database (bad!) because it was the fallback. 

Here's an example from Focus Lab's EE Master Config for ExpressionEngine:
https://github.com/focuslabllc/ee-master-config/blob/master/config/config.env.php

As a side note, the "Foolproof Multi-Environment Config" could probably use the strtolower() function on the 'HTTP_HOST' variable as Bjørn Børresen points out in a commit message in the EE Master Config.

switch (strtolower($_SERVER['HTTP_HOST']))



  HTTP_HOST should be made lowercase as one cannot guarantee that it always is (most browsers do this, but not all) - in which case the wrong config will be loaded