Currently it's impossible to create new global functions in a theme or user layer. The reason for this decision was to prevent the situation where later the core layer or a layout layer gets a new function which has the same name and parameters as one in a user or theme layer but a different purpose, thus breaking any styles using that user or theme layer.
Right now we have a hack in place allowing layouts to declare new class methods as long as they have a name starting with lay_. This hack only applies to this specific case. I'd like to propose a more general solution: rather than little hacks to handle cases like these, let's say that any layer can create any function or method it likes as long as it starts with its layer type. User layers would have to call their functions user_something, and similarly theme layers would use theme_something (or Page::theme_something. Since there can only be one of each layer type in a style, there is no chance of conflict.
We can also extend this to declaring new classes. Right now any layer can declare a class, but this shouldn't really be the case and in certain cases it will break S2's inheritance model which relies on all classes being declared before functions are declared in order to correctly resolve the inheritance heirarchy. Unfortunately, this means that classes would end up with names starting with lowercase letters, like layout_FunkyEntry, which violates the coding style guidelines. I'm not sure whether this matters or not, really. Of course, to avoid the inheritance problems we must prevent layers declaring classes which inherit from classes in previous layers, which might be a pain since right now the compiler just retains one unified checker for the entire style so far.
We can keep the current lay_ special case around for compatibility in addition to the general layout_, but I'd like to stop other layers declaring undecorated classes even though this breaks backward compatibility. I'm hoping that there aren't that many people out there relying on non-core classes and that they'll be people who will understand the error message that results when they recompile such layers. The layers will go on working for now, but it will be impossible to recompile them without fixing them, so we won't just get bajillions of dead journals as soon as the code goes live.
As ever, I'd like to invite discussion on this.