The names of the php classes stored in the db should/could be corrected to their camelCase version (and of course they come from the php files where datatype php classes are defined - data_type-string costant, so those have to be fixed too).

Rationale: in ezdatatype loadAndRegister function, the string value gotten from that column is used to search for a suitable file to be loaded that contains the php class definition (via some ini params).

If the class name had the correct case, we could take advantage of the new autoload capability to find the correct php file to be loaded, eg. via a simple call to class_exists($classname, true).
This way, if an extension changes the autoload path (which it can do), it can also redefine a standard datatype class with its own implementation.

Note that that might be considered a good thing or not. Imho having more flexibility is a good thing!

Otoh here are some drawbacks:

• provide a db upgrade script for migrating installs
• if existing extensions rely on string comparison of datatype classnames, they might break (but extensions need porting to ez4 anyway)
• if a pure autoload mechanism is used, the ini parameters cannot be used as a fast switch to disable loading of a single class (but preventing loading a php class after having used it as a datatype for content objects does not make much sense anyway...)