The Grumpy Editor encounters the Hardy Heron

Actually, that is just a specific example of a general principle: NM is not ready for LTS, or
at least it should not be enabled for all LTS users.  Whether that's because of problems in NM
itself (which there do appear to be, such as the /etc/hosts mangling) or because Ubuntu (and
Fedora, from comments here and other places) just haven't managed to integrate it properly, is
almost beside the point.  If NM is going to REQUIRE changes to fundamental infrastructure that
has existed for decades before it will allow your network to operate correctly, then that
infrastructure needs to be changed and working BEFORE NM is deployed, especially in an LTS
release.

My second point is that the current apparent design solution for deploying NM (modify the code
of all network-related services to grok NM dbus messages) is fundamentally WRONG.  It's not
portable, it's not scalable, it's time-intensive, it's duplicating work, it's error prone, and
it's not The UNIX Way.  Whether that's how NM recommends it should work, I don't know: maybe
it's not NM but rather the distros trying to integrate NM that are making these decisions.  I
already suggested one way that NM could mitigate this, by providing a wrapper utility that can
manage dbus messages and translate them into "traditional" network service operations.  You
suggest another way, which is to enhance the network services to use Upstart which,
presumably, is already integrated into dbus, rather than, or in addition to, the traditional
sysv init scripts.  That would be fine with me as well.

Basically, NM may be great for people with complicated network requirements but it just breaks
things for people with simple network requirements, with no added benefit.  This is
unacceptable, especially for an LTS release.  Whether that's NM's fault, Ubuntu's fault, or a
combination I'm not sure.

There's more to it than that - if the network connection is at all bouncy (on laptops it's
relatively likely to be so) you end up needing to kick services that depend on it whenever
there is a network status change.

It doesn't remove localhost; it removes your local host name (or maybe it mangles it, I can't
remember exactly).  So if you name your system "myubuntu", that name is no longer correctly
present in /etc/hosts which means sudo does not allow you to log in.

FYI, here's the Launchpad bug:
https://bugs.launchpad.net/ubuntu/+source/network-manager...  Note that I had the
same failure on my system by disabling "roaming mode" in my network config applet and setting
my system to use DHCP.  This is all through the GUI, using "supported" methods of configuring
the system.  There have been reports that just upgrading to the new release caused this
problem, although I did this on my system at home last night and it worked (I didn't try to
reset the network config though).

There is also a bug reported against sudo for this:
https://bugs.edge.launchpad.net/ubuntu/+source/sudo/+bug/...  Contrary to the strident
assertions of folks like asmoore82, I do believe this is a bug, or at the very least an
important enhancement.  Or, if not, maybe it's proof that sudo is not the right solution for
Ubuntu.  I actually really like this model of no root password / use sudo for everything that
Ubuntu uses... but there should NEVER be a situation where a simple thing like messing up your
/etc/hosts file causes you to no longer be able to log in with administrator privileges and
FIX a problem like messing up your /etc/hosts file.  A typo in a file like that should NEVER
require resorting to the rescue disk, mounting a partition by hand, and editing the file to
fix the problem.

As I said, it's enterprise environments where it fails.  Sure, simple home users with a cable
or DSL modem serving DHCP, or connecting to your local Starbucks wifi or whatever, have no
problems: everyone uses that model and of course it works properly.

It's when you start needing lots of OTHER network services, like NIS, autofs, etc. etc. that
we hit the "there be dragons" areas where Ubuntu has not done the due diligence to make sure
their super-cool new features don't break traditional, long-standing, it-just-works
facilities.

BTW, adding a script to if-up.d won't work: the problem is not that autofs starts before the
network interface comes up: autofs actually doesn't need the network interface to be up IIRC.
The problem is that autofs starts before NIS binds to its server, so when autofs starts and
asks NIS for its maps, NIS doesn't give it any maps, so autofs doesn't set up any automounts.
What needs to happen is autofs cannot start until AFTER NIS has finished binding to its server.

I don't know of any way to do that in the current Ubuntu LTS release, short of creating some
script that runs in the background and queries NIS to see when it has maps available, then
(re-)starts autofs when it is.