I'm not convinced this would work very well. when loading a data value, you have to know ahead of time what type its going to be - float or string.
As I understand things, istream::peek() is always going to work, meaning that you could check to see if the next char is, for example, an 'n'. If so, this would indicate that nan was written; otherwise, a normal float could be read. At least in the toy code I've written, this works. This approach (assuming it works completely) has the benefit of not requiring extra information pertaining to the nan-ness of the value. It has the downside, as you point out, of taking some extra cycles. I'll address this in bit.
b)define a special type for Nan: c) a simpler approximation of the above could easily be made. ... The problems I have with these approaches deal, essentially, with the cognitive load on the programmer. Now a serialization lib user has to remember to use the wrappers if dealing with NaN, or face the wrath of a compiler that is not going to tell you what broke when you try to read a NaN. Maybe this is not as big a deal as I suppose, but I can envision scenarios where this would be a problem.
These approaches (although I haven't seen the variant serialization solution) would incur extra storage for each float/double. So, taking all of your comments into account (I hope), I have another idea. Would it be possible to make the text-primitive functionality of xml and text archives a programmer modifiable property? The most obvious approach, I think, would be to give the archive_impls a template parameter of TextPrimitive. Rather than having a hard-coded inheritance from basic_text_i/oprimitive, this TextPrimitive would be the base class. By default, of course, the basic_text_primitives would be used, but alternatives could be supplied by anyone. This has, I think, the great benefit of keeping the primitive representation and overall file structure orthogonal. Again, I'm waving my hands a lot here, but I don't see any reasons in the code why this couldn't be done, but neither do I have intimate knowledge of the code. Austin Bingham