My apologies as I am still only very slowly coming up to speed on this "New Math For Lucene" stuff. It feels like there are three distinct issues in play:
1. Desire to use the latest and greatest Lucene numeric field types. Granted, they are currently now called IntPoint, FloatPoint, DoublePoint, etc., but functionally they are still simply int, float, and double values - no semantic difference, just the class names and then some method name changes for indexing and query. My feeling is that we should preserve the legacy type names even if Lucene insists on calling them "points." Keep user schema files unchanged.
2. Desire to work with existing data - and existing schema files. Mix metaphors: cans of worms and nested Russian dolls.
3. Desire to auto-upgrade existing Solr index data to new "points" for better performance, reduced storage, reduced memory, reduced heap.
1. Personally, I think it would be worth the effort to see if the Lucene guys can stick to to old names for IntField, et al even if the implementation is different under the hood.
2. Maybe there will be a need to be able to open an existing numeric field, discover that it is legacy numeric field (trie), and then under the hood use some wrapper to maintain the new API for the old format. IOW, switch Solr to using the new API, even for legacy numeric fields.
3. Seems like there is some need investigate the possibility or a NumericFieldUpgrader to rewrite a trie field as a point field. Seems like a necessary job for the Lucene guys for existing Lucene indexes, even if Solr wasn't in the picture.