As far as the main thrust of the topic, of course bundling helps--a lot--but maybe the exec just meant that bundling can't suppress good things forever...
Anyhow, the question of what to do if Firefox does gain a 2/3 market share is still valid (and even before that).
My hope is that more aspects of the Firefox browser can become or contribute to their own standards--and that Mozilla will itself adhere to them. XUL, the interface language used in the browser itself and extension building, might be such a candidate for standardization (or at least a subset of it), assuming other browser makers would be interested.
Perhaps there's a lesson somewhere with XBL, assuming it ever goes anywhere (the extensibility of XBL is great, but again, there should, I feel, be some standard for the more frequently recurring bread-and-butter requirement of describing browser elements, as XUL provides).
Likewise, it'd be great for XPCOM functionality to somehow become accepted as XBCOM (cross-browser). Perhaps FUEL API's could be joined with other browser makers' libraries into a standard, again assuming interest. At the very least, I hope other browser-makers-which-allow-extension-of-the-browser may agree to standardize on Mozilla's useful JavaScript module importation so that such code can also be reused cross-browser without modification.
One concern I have is with an existing attitude in Mozilla where repeated mention has been made by prominent Mozilla developers of a distinction between the web and non-web, and arguing against following standards which were conceived without the web in mind. While that may well be true, this can also set up a false dichotomy and introduce exceptionalism. If there is a non-web use for a technology (e.g., support for external DTDs in (especially document-centric) XML for simple localization), then there well is also a web-use. Likewise was such an argument against certain standards made toward not implementing DOM Level 3, even though parsing and serialization from or to strings or the DOM is a pretty basic requirement across browsers (and the API, as with the rest of the DOM, is not that terrible so as to make it impossible to work around, as we all do with levels 1 and 2 of the DOM). I hope such existing cross-browser issues can be addressed, even as new standards if need really be (again, without falsely assuming that non-web uses such as serializing to streams, etc., can't find web (or browser) uses and dumbing down the standards).
I'm also concerned with another topic impinging on the Mozilla-as-gatekeeper concern: modularity within Firefox itself. Firefox should, I feel, quickly make good on its plans to enhance its extension dependency system, so third parties can supply independent modules and have extensions automatically trigger such downloads upon installation. Otherwise Mozilla stays as the albeit friendly gate-keeper within the community (not to mention for other browsers) and either gets bloated or left insufficiently extensible. For example, for dealing with the sparseness of built-in JavaScript functions to handle many common tasks, while using an already familiar API, PHP.JS could eventually be made as such a module. Mozilla expressed openness to allow modules to be added, but it would, I feel, be more extensible and sustainable into the future (and not contribute to browser bloat), if the community "market" could more easily determine which modules were useful as reusables. Thus, extension builders could freely rely (on an ever-expandable number of) reusable but optional dependencies without burdening users into initiating separate downloads (or downloading or reloading the same code repeatedly across extensions, or unnecessarily updating the whole package when only one module needs updating). In the process, this could significantly address the arguments made by some against installing too many extensions.