We still use libLAS (and LASlib by the way, you can test it by selecting the 'LAS 1.3 or 1.4' filter and see if it changes anything).
The issue your customer has, typically looks like an accuracy issue... just as if they ignored the Global Shift mechanism (and the associated warning ;). In CC we store the coordinates as 32 bits floating point values, which prevents from storing large coordinates 'as is'. The Global Shift mechanism is used to temporarily shift the coordinates in a local coordinate system (while the clouds are processed in CC), and they are restored at export time. This mechanism works great and prevents any loss of accuracy. It is also sufficiently smart to let the user load several clouds in the same 'local' coordinate system, to register the clouds with GCPs expressed in the global coordinate system, etc.
Apart from users periodically ignoring the warning message at loading time, I don't remember any other severe issue related to LAS import for a long time. However if you feel this is another issue, don't hesitate to send me a sample file.
For the GPS time scalar field, we have the same precision limitation (as the GPS time field is 64 bits). But in this case the field is automatically split into two fields, one with the 'high' part and one with the 'low' part. It may explain why the field looks funny. But once again, the fields are merged back at export time. I don't know which version you are using, but as this is something generally overlooked by most users, this may be a separate problem. Once again I think a sample file would be very helpful so that I can clear any 'suspicious' behavior from libLAS or the LAS importer.
Daniel, CloudCompare admin