Conform to whatever is committed to MRI. There is a standard, but it's not complete enough to ensure compatibility. The standard is describing what is already there and not meant as means for designing the language. No review process for patches.
There is the RubySpec project, which all implementations usually run at least before doing new releases. It's not currently used for designing the future of the language and all teams but the Rubinius team consider contributing to it on regular basis as too much overhead.
There is an ANSI standard, but it's not complete enough to ensure compatibility. The standard is describing what is already there and not meant as means for designing the language. Kent Beck and others criticize "Balkanization of Smalltalk" (i.e. it is not possible to write Smalltalk programs without targeting a specific implementation). No maintained reference implementation.
Alternative implementations may not be called PHP. There is no standard. Language design is interwoven with implementation design. Language quality is often criticized.
There is no official implementation, just an official test suit. In contrast to RubySpec, this is where language design is happening. There are multiple implementations treated as equals.
Standardized bytecode with well defined behavior, lots of implementation. Everyone can participate in the Java Community Process. Two implementations treated as reference implementation (OpenJDK and HotSpot).
New features are proposed via formalized process Python Enhancement Proposals, everyone may participate. Van Rossum has veto. Reference implementation. Situation close to Ruby, but formalized process.
Decided on by C++ Standards Committee, no official/reference implementation.
Decided on by ISO working group, no official/reference implementation.
Core language is designed by Ecma International (non-profit committee), client-side stdlib is designed by W3C, server-side is designed by CommonJS committee. Hard to propose changes if you are not in the committee.
Uses Erlang Enhancement Process, which is similar to Python Enhancement Proposals, but officially hosted on GitHub and proposals can be submitted as pull requests. Process is highly standardized.
Scala Improvement Documents, similar to PEPs and EEPs.
I see. This brings up another important point regarding prioritization. A discussion needs to occur on how often cases like these occur, so items that have the greatest impact on a large number of users are presented for clarification first. I'm not sure if such a process is in place, but there does need to be one. Otherwise we're stuck with an overwhelming TODO list.
I raise a flag here because this could require a lot of resources and time dedication depending on how detailed it's made. Before we put anything encoding related in a spec I think there needs to be a comprehensive discussion on how Ruby handles encoding now, and if it's the best way. As encoding could be a potentially complicated subject, we should make sure the architecture itself is solid before spending time writing about how the different processes work.
This is a bit tricky to respond to without knowing what areas would be touched upon specifically. Are we just talking about threads and process forking? How will system dependent issue be handled? Windows, for example, does not have fork:
http://msdn.microsoft.com/en-us/library/y23kc048(vs.71).aspx
This is an important point as the level of detail in how system dependent issues are handled could drastically alter the timeline.
Are there tags/labels for this in redmine to sufficiently address this?
Good question. Does this exist at all, even if it's in Japanese? If it's in Japanese just point me to it and I'll translate and post to -core. Of course, this brings up the issue of "what about new features in the future?" I envision the process as something like:
For purposes of addressing the issues, changes should be reported as a bug along with why that change is being introduced. Are there specific instances where this is not happening?
In what context? Where is 1.9 compatibility mentioned in a way that requires clarification?