Facing works well in boardgames where you can simply and naturaly place a figure slightly different. In a computer game you need separate buttons for rotating, which complicates interface and legthen the turn.
Facing might be OK if you meant it like direction you face after you finished your turn, for overwatch fire.
I disagree that facing is always going to be an unnecessary complication, particularly since the game resolves almost entirely around combat - notably a unit will only ever move in the direction that it is currently facing (unless that unit is something like a Hover Tank, but this is not something I need to worry about since my units are largely on foot), ergo the unit's rotation would be derived largely from it's intended path of travel. The exception comes only in two places - at the end of a unit's movement, or if it wishes to pause. The former is something that seems fairly natural to me in this kind of game, and the additional user cost of performing the action is relatively minimal. The latter is something that I may not allow for, as if units have a small number of movement points (enough to move 3-5 tiles at best), it is potentially not often possible for a unit to gain a real advantage by moving, rotating, pausing, rotating then moving again (if there is one, I can't really see it!).
Had there been longer movement ranges, a larger volume of units or otherwise more to do on a turn-by-turn basis, I may well have reconsidered this stance, but as it stands I don't think it's much cause for concern.
Test when moving into a cell... but test for, "Do you have any points left?", not "Do you have enough points?".
This allows the unit to move into a cell even when the unit doesn't have enough points, as long as the unit has some points so they can always move at least one tile, even through the worst of terrain (Obviously excluding terrain which that unit is never allowed to walk on, like water if a non-water unit).
This is an excellent consideration and one that I may well elect to adopt!
You could do both. Double the amount of movement points each unit gets and subtract the points for moving into and moving out of a block. Example: If you have a piece of rough terrain that costs 3 movement, then the unit will lose 3 moving into and 3 moving out of. This would only be useful if movement points can be used for something else. I think doing it this way would more closely represent movement since you aren't traversing the entire terrain unless you move into and then move out of. If you only one or the other then you haven't actually traversed the whole terrain segment, only part of it.
This I brought up in my previous posts - there are advantages to doing so, though I'm less worried about closely representing movement types as I am about better representing terrain types. Note in my example a hill or a slope; it would be much easier to descend the hill or slope than it would be to ascend it, ergo you expend two movement points entering that tile, but only one to leave it. My only worry is that a two-costed system may not be adequately transparent when it comes to moving units, though I suspect some decent UI work may help rectify this.
Now, maybe one would just need a different UI than what I went with there, but as the number of possibilities get large, one either has to revert to moving the unit manually one square at a time (with the UI you mention, much like the Mechwarrior Tactics game does), or you end up with a mass of possible moves that could overwhelm users. (The UI there looks much the same if I use a scheme for 1MP = 1 Hex facing change)
Thanks for the link - I'll check it out! Units could indeed end up having their paths selected one tile at a time (turns are taken simultaneously, then when all players / AI are ready, movement and result occurs simultaneously) and this is something I'd like to avoid. The game does feature relatively small and object dense environments as well as fairly short movement ranges, so the number of possibilities should be relatively small rather than overwhelming.
Another option is like you said, not worrying about it until the move has been done. Either giving it a cost to move any number of facings, or zero cost to set its facing anywhere. That's probably the best for humanoids anyway, since we can all turn fairly easily (except when running full tilt, but that can be done as a separate move if one really wants to get complicated)
Humanoids perhaps, but groups of humanoids can be more tricky to organise 
- I'm currently assuming that short turns are free and taken as part of regular movement across a tile (60 degrees), but a wider turn would incur movement cost (120 or 180 degrees). The movement cost would probably be fixed rather than dependent on terrain, since terrain already incurs cost for moving across it, so you're looking at one point for a sharp turn, possibly two for doubling-back on yourself.
You could also calculate the chance of moving into a cell by the fraction of remaining/needed points.
This is certainly an interesting proposition, but I think I'd like to avoid chance being brought into core movement mechanics. At present, players can be slowed down by opponents and end up not making their desired moves, but this should hopefully feel more like a punishment as the result of making a mistake, rather than being the result of bad luck!
How many terrain-types/different movement-costs are there, btw ?
Are all units capable of moving over all terrains ?
How many cells do you want a unit to traverse at maximum ?
how many at minimum ?(using up all movement)
How many should be "average" ?
For the sake of clarification:
1) I don't yet know how much variation in terrain there will be, but probably not much. We're probably only looking at two or three basic terrain types and possibly one or two additional properties such as the aforementioned hill or slope.
2) As mentioned in my previous post, the slowest units would probably manage two or three tiles per turn, the fastest around five.
3) Units don't have to go anywhere. Worst case scenario, the slowest unit could be bogged down and travel only a single tile.
4) I don't think average is relevant in this context. Movement is dependent on unit type and terrain effects. There'll be a natural variable range, but any average depends on the player and game environment.
How will movement be determinded ?
Do you give an order to a unit and just see how far he goes, possibly getting stuck at a place you don't want him to be,
or do you send him from one hex to another, and when he still has movement points left you move him again ?
The former - if it were the latter, my previous post probably wouldn't have made much sense ;) You give orders that include a simple path, and the unit will attempt to complete them. A unit will fail to complete them if it's movement is impeded by another unit, allowing for some unpredictability in the game play (and some second guessing the intentions of your opposition).
Thanks for the comments everyone - very helpful!
Edit: Cleanup up a broken quote box.
