Meteor's release notes for version 0.9 elaborate further on this new packaging system:

Incorporating lessons from our community's Meteorite tool, Meteor 0.9.0 allows users to develop and publish Meteor packages to a central repository. The meteor publish command is used to publish packages. Non-core packages can now be added with meteor add, and you can specify version constraints on the packages you use.

Binary packages can be published for additional architectures with meteor publish-for-arch, which allows cross-platform deploys and bundling. You can search for packages with meteor search and display information on them with meteor show, or you can use the Atmosphere web interface developed by Percolate Studio.

The announcement was met with divided reactions from the developer community, and in particular on Hacker News. In the discussion linking to Schmidt's article, user untog was cautious in their response and unsure of the benefits. They said:

[It] sounds interesting, but the devil is in the details. To use their example, HTTP.get() will have to deal with CORS on the web, but not in apps. If you end up with dozens of "for X you just need to add Y" situations then the utility is kind of wasted.

And, to be honest, I still don't get why this requires a new package manager, npm (with a utility library, perhaps) could perform most of these functions.

Others were less guarded. On Reddit, in a similar discussion relating to Schmidt's article, user sigwhitesaid:

Tons of modules on npm are already being used to create isomorphic code, thanks to tools like Browserify.

It's not that you can't write isomorphic code using npm (in fact, that's specifically what Browserify allows you to do), it's that flooding npm with thousands of Meteor-specific wrappers wouldn't be very helpful to anyone (especially when that code provides no value outside Meteor, and non-Meteor modules aren't easily integrated.)

The reason Meteor has its own package system is the same reason it has its own build and project management tool: it's a fully-integrated solution (more than just a "framework")

In defence of Meteor, Meteor is making a heavy use of fibers. Packaging a npm module is not that useful. Making a package abstracting callbacks and async to make it play nicely with Meteor is the way to go.

Meteor would heavily profit from accessing the whole npm ecosystem without having to abstract anything, but abstraction is the key here. Meteor is trying to unify the node and clients APIs.

Away from the Isobuild announcement, Meteor's release notes list various improvements to Meteor in version 0.9.

Among the improvements were items such as that changes that only affect the client no longer require restarting the server when running your app with the local development server, in the latest release. Similarly, changes that only affect CSS no longer require the browser to refresh the page, both in local development and in some production environments.

The major version's release brings also an update to the appcache package, with it now functioning on all browsers that support the AppCache API by default, rather than a whitelist of browsers.

The release notes elaborate saying "The main effect of this change is that appcache is now enabled by default on Firefox, because Firefox no longer makes a confusing popup. You can still disable individual browsers with AppCache.config."

A full list of changes, including packaging-related changes, can be viewed here.

0.9 is the last major milestone before Meteor's 1.0 release. Version 0.9.0.1 has recently been released with some minor fixes for issues.