I know this is a bit of a moot post, since the decision has been announced to be rid of the prefixing, but I think some of the finer points of this conversation bear commenting on.
Personally, I vote for three distinct namespaces:
1) one for MXML 2006/Halo/Flex 3 - xmlns:mx="http://www.adobe.com/2006/mxml" or "library://ns.adobe.com/flex/halo", whichever
2) one for MXML 2009 native language elements - xmlns="http://ns.adobe.com/mxml/2009"
3) one for Spark/Gumbo/Flex 4 components - xmlns:fx="library://ns.aodbe.com/flex/halo"
This allows the MXML specification to evolve on a separate timetable if it needs to: the next MXML specification after 2009 may not be until MXML 2011, while Flex may be into version 6 by then. This actually makes it easier to distinguish MXML as a language with its own syntax, i.e. having its own manifest file, rather than a prop for one framework or another. Having some experiemce in teaching Flex and responsing to beginner tutorials, IMO collapsing namespaces will actually make it harder, not easier, to teach and explain Flex to the beginner.
Keep in mind that people can reassign URIs to whatever namespace they see fit, so I would not get to hung up on whether a URI/manifest file is undeclared or is assigned a specific namespace name, although having the MXML 2009 be the undeclared or default namespace (i.e. xmlns="...") is a good convention.
And as for prefixing, I think it's pretty unanimous how much of a hack and forwards-compatible disaster that would be. Enough said.
As for CSS, I don't see an issue with using namespaces in CSS as Matt Chotin suggested. As for allowing/disallowing something in the CSS spec simply because global class selectors or some other technique is not a best practise is ludicrous, and this /will/ harm beginners coming to the language. There needs to be room for people to implement hacks and bad practises if they want to, because quite frankly there is a reason to buck the rules and write not-so-elegant code on occasion. I should have the option to use a namespace with a global class selector to define a style on both a halo Button and a gumbo/spark Button if I want to.
As for why people would want to use two different namespaces or packages for teh same component name in the same file, whether MXML or ActionScript, well we won't all have the luxury of coding perfect J2EE-OOP-patterns-compliant code all the time. Having come up through the Flash coding world, I know just how much hacks are a fact of life, despite how undesirable they are. I can well see a "conversion project" down the road where I'm tasked with adding Flex 4 capability onto a Flex 3 project. If I need to add to a component with 10 Flex 3 Panels but I need the functionality specific to the Flex 4 Panel, I sure as hell am not going to recode all my Flex 3 Panels if I can at all help it. I'll just live with and deal with a new namespace declaration in MXML and use fully qualified class names for some components in ActionScript. If the project is configured for both Halo and Spark component frameworks, then my tools (i.e. Flex Builder) should be intelligent enough to help me with fully qualified class declarations as well.
So the solution should not be dumbing down and simplifying simultaneous framework implementations for the sake of beginners. Beginners have already shown that namespaces are intuitive, and anyone used to coding in ActionScript should already be aware of import collisions and know how to account for it: we shouldn't be implementing hackneyed solutions so beginners do not have to learn core programming skills. And the tools should adapt to new framework/language conventions, not the other way around.
Personally, and I apologize if this sounds a little harsh, but I think the engineers at Adobe need to tell the suits to wait until equivalent spark components are developed to complement all the halo components before Flex 4 is released. And still allow for simultaneous use of different major framework versions. Unless... it is publicly acknowledged that Flex 4 will stay in Beta until this happens. Putting out an unfinished product just to meet some marketing forecasts doesn't sit too well. You want to improve Flex Builder? Fine, issue a point release of Flex Builder 3, or diverge the tool versioning from the SDK versioning, which is what landed up happening with Flash Player/Flash Authoring.
