There are some basic problems with serialisation of basic data types that need compensating classes and dependencies that make it hard to separate out and share library code.
I have in a utility class the following code, which compensates for missing / broken functionality right at the data types level of Eiffel:
The first two branches compensate for the wrong behaviour of DATE_TIME_DURATION and DATE_TIME 'out' feature, which return respectively a non-ISO8601 duration string, and a (useless) US-style date/time string. In both cases, I think it's pretty much globally accepted these days that the output should be ISO8601-based. At the moment I have to suck in my ISO8601 library to do this.
The 3rd branch deals with the problem that when a REAL is serialised to string, if it happens to be integral in value, there is no '.0' included. I rely in the ODIN library on consistent syntax of basic types, both on input and output. So ODIN parses values like 3.14 and 3.0 as Reals, but it will parse 3 as an Integer. I can't remember what the Eiffel compiler does, but I think it's the same. In ODIN, any Real is output to string form with a decimal point and a digit to the right, which means the round-trip is symmetric. Eiffel's 'out' routine for Real doesn't, and that breaks ODIN.
These hacks are needed quite deep in my libraries, not just in ODIN. For example, I have a some Interval library classes, based on a parent class INTERVAL [G->PART_COMPARABLE] which are commonly used with Reals and date/times. INTERVAL has an out routine that would serialise instances of types like INTERVAL [REAL] and INTERVAL [DATE], if only the 'out' routines of those types were not broken.
Problems like this force me to have annoying extra classes and dependencies I don't want, thus gluing up libraries that could otherwise be separated out and shared freely. I can't be the only one in this situation.
Is there any prospect of things like this ever being fixed?
In the openEHR (EHR = Electronic Health Record) project, we use a serialisation that is called ODIN, an alternative to JSON, XML etc. It was developed before JSON existed, and is more comprehensive (particularly in terms of leaf types). It is also (in my view) easier to read. It's certainly easier to write (in JSON,  and "" will eventually drive you crazy).
I am leading a workshop on Monday 27 June 2011, at TOOLS 49 in Zurich on the idea of developing a worldwide New Eiffel Technology Community. The idea is that languages that survive like Java and Ruby today don't depend on the qualities of the language, but on the qualities of the 'technology stack', i.e.