Our county data will differ from GSAK in almost all countries, for different reasons. The products will update the polygon data in different points in time, meaning that one might have newer data than the other. I can't speak for GSAK, but Project-GC always strive to have as accurate data as possible, regardless of how many vertex points the polygons are. Having polygons with very many vertices makes them slower to work with, but that is not a problem for us at least.
But, handling polygon data takes a lot of time. Especially to produce new polygons and update the data. It requires a good data source, understanding of the data, and Geocaching.com's country divisions. Sometimes we get help from the community with the data, and I am sure GSAK does as well. This is another case where we will not end up with the same data.
Project-GC's most common data source for this kind of data is OpenStreetMap.
Regarding if there is county or not in the name; We use the tiger data as our source for USA, we use the names that they use.
The state abbreviation has been added to remove conflicts of the same county name over several states. It makes it easier for users and it fixes some of our design issues in the code where we over and over again have assume that county names are unique within a country. A similar case exist for Australia.
If your issue is GSAK, I suggest importing into a separate database and then run a macro that fixes counties on all of them. When the counties are "fixed" to be compatible with GSAK, merge the databases.
