i think we are a bit of disadvantage because we use unclear terminology.
let me say how i see it:
of course there is a "core". the core provide infrastructure services such as DB interface, session management, template processing, loads and call the plug-ins etc.
in addition, there is another distinction: "in-the-box" (aka "builtin") vs. "add-ons".
the important point is that not everything "in-the-box" is necessarily "core".
the idea is that a lot of the "in the box" capabilities are implemented as plug-ins and use the plug-in interface.
so the "in the box" consists of a lean-and-mean core, and a bunch of plugins. the user can enable and disable each plugin as she sees fit.
she can also add plugins not originally in the package. there is little distinction between "in the box" plugins and "addon" plugins. they behave exactly the same.
as much as possible of the "in the box" functionality can (and should, IMO) be a plug-in.
this has several advantages:
-- by minimizing the core it becomes more stable. only changes to the core require "upgrade". everything else is handled through "install a new plug-in version" which is significantly simpler than an upgrade
-- every feature which is implemented as a "plug-in", automatically gets enable/disable switch which operated exactly the same
-- we can much more easily fix bugs in specific plugins, and publish those fixes, or, worst come to worst, publish a warning: "version X of plugin Y is severly broken. until a new version is available, please disable plugin Y".
-- it is very natural to select a well-written, well-documented, well-supported popular external plugin and promote it to "in the box" status: in essence, it becomes a packaging question.
so, the way i see it, it is extremely important not to conflate "core" and "part of the basic package". probably some new terms should be used.
maybe we should retire "core" and use "kernel" and "basic package".