I'll take a crack at it if you can get rid of the "etc". That is, if I'm going to put in the work to provide answers, you need to put in the work to provide all of the questions that need definition. Fair enough?
Q1.1 Firstly, what coordinates do you use for storing the positions of stuff in the game? You seem to have answered that everything is stored as lat/long coordinates. That's fine.
First thing to note: when stored, lat/long coordinates make everything look like it's on a rectangle (in terms of storage).
Q1.2 What precision are these coordinates stored with? For example, will you store them to 1 decimal place? Will the precision depend on the size of the globe? If so, how would you describe that dependency?
Q1.3 Can the precision of the coordinates stored depend on the latitude?
e.g. Suppose you went with lat/long coordinates with 1 dec. place of precision. Is it ok that the coordinate resolution is finer near the poles than it is near the equator? Even if the answer to this is yes it doesn't mean there'll necessarily be any problems later.
Unit Movement:
Q2.1
If we are aiming to overlay a hex grid for the sake of moving a unit, how would that grid be positioned?
e.g. Is it centered such that the unit's position (a point - lat/long coordinate) is in the direct centre of a hexagon?
Q2.2 What camera angles are allowed? We talk about angle and pitch. Angle can be anything from 0 to 360 and basically refers to the compass direction the camera points. Pitch is 90 degrees for a birds eye view, 0 degrees for a horizontal view (e.g. a person on the earth looking at the horizon).
Some reasonble answers I can think of:
-pitch always fixed at one of two angles (maybe 90 and 45 degrees) while angle is always fixed to be 0 degrees (i.e. north to the top of screen)
-any angle allowed (0 to 360) but pitch fixed at just a single angle like 60 degrees.
-any angle and pitch are allowed
Q2.3
What hex orientations are allowed?
e.g. Suppose you can rotate the camera to any angle. Is the orientation of the hex grid overlay dependent on the camera angle or dependent on something to do with the sphere? (An example of something that would depend on the sphere is that the north direction is always a possible move)
Q2.4 Suppose a unit can move a distance of 2. Can the unit move to any lat/long coordinate within the radius-2 circle centred on that unit? Or can the unit only move to any one of the 18 hexagons around it (and if so can it only move to the centre of each of those hexagons) ?
This leads to question 3.
Distortion of the sphere
Q3.0 For the hex grid overlay, is the aim to represent the surface on a perfectly flat plane on the screen? Will any curvature be visible at the normal camera angle? Will any curvature be visible at any camera angle?
Q3.1 To overlay a hex grid (or a square grid) onto a sphere, some distortion is necessary. You can choose to distort either the hex grid or you can choose to distort the surface (i.e. make it look flat). Which is it you wish to do? Depending how you answer, head to either Q3.11 or Q3.12
Q3.11
Assuming you wish to distort the hex grid and not distort the appearance of the shape of the sphere, how do you plan to make the hexagons look? It should be noted that if this is the desired approach, you can't make hexagons get smaller the further you go from the active unit. If anything you actually need to make the hexagons get larger (in terms of the area they cover on the sphere).
Even if you can't describe this exactly, perhaps you can draw a very small scale picture on this circle. The minimum I need to see in the picture is a path from hexagons at the centre of the view (the middle of the circle) to the hexagons at the horizon (the edge of the circle). I am VERY curious about how you wish to do this. The pic does not have to be pretty. Try to give an idea of the size of the hexagons near the centre and the size of the hexagons near the horizon.
Here is a pic to get you started...
Q3.12
Assuming you don't want to go with distorting the hexagon shapes and instead distort the sphere, how do you wish to do the distortion?
An example of one way to distort the sphere so that you can overlay a flat hex grid is to assume that the lat and long coordinates are simply cartesian coordinates and the gameboard is just a big rectangle with east west connecting together. Obviously this is a "cylindrical" distortion of the planet. If you go this route, and display a hex grid near the poles compared to a hex grid near the equator, you run into the problem that hex movements near the poles cover relatively less distance (on the real sphere) than hex movements near the equator. Is this avoidable or not?
Q4.1 Suppose you wanted to move a unit to the other side of the planet (diametrically opposite). Should it be possible to show a path for a unit to take on that route?
Q4.12 If that route can be shown, does it stick to a hex grid?
Q4.13 If that route cannot be shown (e.g. if you don't allow moving the camera around the earth while you have a unit selected and hence can't see the destination tile) do you accept that for moving a large number of units to the other side of the planet you will have to do 2 or more separate moves?
Q4.131 If the answer to 4.13 is yes, do you accept that the GOTO feature that every civ version has had will either have to be gotten rid of or limited in its range? What range would you limit it to? Perhaps you would instead allow the GOTO feature to take you to any point on the globe but have to say the number of moves to get there is "indeterminate".
Q5.1
Is unit movement the only thing subjected to hex grid restrictions? Is there anything else at all that needs to depend on some sort of hex grid? City positions, tiles that cities work, position of resources and other terrain types.
Q5.2 How do you decide if one unit can attack another unit? Do the two units have to fall in adjacent hexagons with whatever hex overlay is shown? Do the units simply have to be a distance of 1 or less apart?
Q5.3 What is the closest acceptable distance for two units to be from each other? (answer needs to be in terms of the underlying coordinates e.g. lat/long)
Q4.1
Has any consideration been given to the stability and processing time of dealing with calculating distances on a spherical surface? Spherical geometry is not trivial and is orders of magnitude slower than the trivial integer operations used for most calculations in Civ4.
Weirdness
Q6.1
When units move, what is to stop them ending up a tiny distance away from another unit? Or is this acceptable? If you intend to answer this with something about "rounding", please be explicit about what gets rounded and how. As an example, if I was playing a board game on a square grid and units could only be at vertices on the grid, yet a unit could move anywhere within radius 10, I might say that it can move to any vertex that has an x and y coordinate such that x rounds (to nearest integer) to -10 or 10 or some integer in between, and similarly for the y coordinate. This is an example where the rounding is completely explicit because I say "(to nearest integer)" and exactly which points the unit can move to (any x,y coordinates with -10<x<10, -10<y<10)
I will need to ask more questions but which questions to ask will depend on the answers to these questions.