The concept of 'an SBML element with mathematical meaning' has always existed, but in core, it usually is covered by explicitly listing the five elements this describes: Compartment, Parameter, Reaction, Species, and SpeciesReference. However, as packages are developed, this list is being expanded, and references to this list are also being created. For example, there are three elements of the 'qual' package with mathematical meaning: QualitativeSpecies, Input, and Output. On the 'reference' side of things, 'comp' allows an element 'with mathematical meaning' to replace a 'Parameter', as an exception to the 'like must replace like' rule (see p24 of the comp spec). 'Distrib' is in talks right now to extend these five core elements with descriptions of their error--it would be nice if it could simultaneously extend elements from other packages with mathematical meaning to describe their error, as well.
Along those lines, it has been proposed that some SIdRef element restrictions be loosened for packages, in some cases. The target of an InitialAssignment element, for example, could easily be 'an element with mathematical meaning' instead of the current list of five core elements. (If a package is not understood, it is no trouble to simply disregard an InitialAssignment that points to an element from that package--if you already don't understand the element, it is no worse to not set its initial assignment).
Ultimately, this ties into Nicolas's vision of SBML+, where there is a more unified core 'element with mathematical meaning' class and perhaps even list. But I think that a step in this direction could be taken even for L3v2, which would make life a lot more straightforward for packages that deal with mathematics.
At the most basic level, I would propose that we create a new class (called something like 'MathElement'), which inherits from SBase, and from which our five classes inherit. It doesn't even need to do anything; everything could be exactly the same as it was. However, the rest of the spec could then begin to refer to the MathElement class instead of listing the five other classes each time. This would allow packages to define classes that refer to MathElement and SIdRefs that must refer to MathElement objects, in a package-agnostic way.
We could then make MathElement slightly more useful by moving attributes to it: 'id' and 'name' are obvious candidates to start with. Slightly more controversial would be to include the 'constant' attribute and the 'units' attribute: not all of those five elements (nor the new ones in qual) currently have it. You could also standardize the interface for these elements by giving it a 'value' attribute. This would be a more significant change--it would replace the 'size' attribute on Compartment, the 'initialAmount'/'initialConcentration' attributes on Species, and would be a new thing for Reaction, for example.
Another option would be to create a ValuedMathElement that inherits from MathElement and adds 'constant', 'units', and 'value'. It would kind of depend on what exactly people wanted.
Overall, I think a MathElement class, with 'id' and 'name' could be quite useful, and probably non-controversial. The other changes could be argued for or against. And it would make writing the core spec simpler in reference to packages, and would make writing package specs simpler in reference to core and other packages as well.