this looks a bit like you’re having some CRS-related issues. What projection do you use in QGIS for your feature data? I sometimes have issues with “exotic” projections that are not part of the PROJ/GDAL system (ie not described at https://epsg.io).
Safest way is to make sure you use EPSG 4326 (Lon-lat, WGS84) in QGIS (for the feature data, not the QGIS project), check the geometries there and then import/open the features in GPlates. Maybe you can export the geometries (or of a single feature) to a text-based format (geojson, csv, OGR GMT) and visually inspect what feature geometry values are given as x,y coordinates.
Also, if you’re really stuck, it helps to post the data (or an example which causes the same issues) here.
at this time I can only speculate without an example of the data. Can you visually identify issues in the data set you use when you try and load the data in GPlates (GUI) and/or QGIS - are there features missing?
Again, I’d recommend to go through a workflow to convert/export the feature collection from any CRS to EPSG 4326 from QGIS as , as SHP/Geopackage or OGR_GMT file. Then load the exported file into GPlates and try to figure out which features cause trouble.
Running a simple check using awk filtering for the EPSG 4326 based data e.g. values > 360 (or < -180/ > 180) and > 90, < -90 that should point you in the right direction (of course you can also do the same for the World Mollweide using the permitted x-y ranges).
In addition to following Christian’s advice can you PM me a file that’s giving you that latest error message you posted (the one about gcs.csv) ? I just want to check that because we’ve fixed the latest GPlates and pyGPlates releases (ie, 2.3 and 0.36) to deal with that specific error (by including the required GDAL/PROJ data with GPlates/pyGPlates) so I’m a little surprised it’s still happening.