Retracing the other aspect of the issue (no real news brought up here, but I think there still is some merit to the subject):
to conclude: instead of arguing which modules should be in the core, the more interresting question is, how to we actually implement the split.
The question "What is (constitutes) Pike?" actually _is_ crucial to which choices we make in distributing Pike (ourselves), for the same reasons you mentioned - as long as we mind our image of how you need to go about to run a Pike application. Some core developers still do, some don't. I like Bill's angle of naming the close-to-today's version "Pike", the ultra-slim version "core" and a massive be-all-end-all "full".
A Debian installation (of the package "pike") does not meet the same standards a new pike.ida.liu.se Pike release does today (since some of the people who perform the release cycle work won't consider the work done until it supports SDL, mysql and to have a working pike -x module to name a few criteria). Users working solely within the Debian package management system when running Pike applications won't notice this, as long as they only run packaged pre-built applications who pull in the parts of Pike they lack by power of debian sub-package dependencies (pike-mysql et al).
Running an application that requires some aspect of Pike that the Pike on your system doesn't have does not fill (pike -x module is broken, there is no GTK or SDL module, for instance) would ideally fail quite gracefully, pointing out what is wrong. Core Pike may not excel in this department, but it is very easy to make that situation worse when stripping out hereditarily assumed-always-present modules. (Especially since we don't have the Python tradition of starting every file with a manually maintained list of component dependencies. OTOH our compiler is probably good enough not to need any such help.)