Thanks for the explanation, Jasem. Let me just comment a bit, maybe it will help in deciding the directions.

1. Migrate to new INDI properties.
   Most welcome - I, frankly, lost track of the rapid API development in INDI.
2. Add missing features (Track Modes, Track Rates)
   These may or may not be tricky to implement. The main principle of the driver is: get the RaDec for the object at this exact moment and point the scope at this direction on the sky whatever the directions of the axis are.  It gets there by sending gotos to the particular encoder positions and the calculating instantaneous angular velocities of the axis and updating them periodically (often, possibly too often even). So if we get recalculated positions of the planet, comet, asteroid for the current time it will follow its movement. Although, at present the tracking code does not update RaDec of the target after goto which leads to moon drifting slowly. Eliminating this assumption should not be that difficult if there is some way in the INDI API to update RaDec of the target during tracking without goto.
3. Add more useful information (raw encoders)
   The data in AUX stream is really not encoder positions. These are angles calculated by motor controllers. Just presented as integers. I do not think the raw encoders are present in the AUX protocol.
4. AuxProto was overhauled.
   Some changes there seemed to me a bit too radical - but this will show up in testing quite quickly, and simplification are usually beneficial.
5. Simplify the driver.
   I agree, it got pretty convoluted at places. Fresh look will definitely help.
6. Custom parking position? Not sure about this yet.
   This was on my todo list. E.g. I have only ESW horizon. Parking to the north is annoying and means long initial rotations, cord wraps etc. In my case it is only annoying, in some other cases it may be impossible due to physical constrains of the environment.

1. Are you certain the 24bit values are SIGNED? It appears I'm getting conflicting reports about them being unsigned as well.
   I am sure of nothing, really. But they seem to be. The docs indicate so: 
   github.com/jochym/nexstar-evo/blob/maste..._AUX_Commands_10.pdf
   Page 13  Table 3: "Position is a signed (24bit) fraction of a full rotation."
   In my experience, they seem to be twos-complement 24bit signed integers for ALT and 24bit unsigned ints for Azm. I think that due to the properties of the twos-complement representation and periodicity of angles this may be the same, actually.  But we can test it easily enough.
2. getNorthAZ is used for what exactly? Is it supposed to be 0 for north hemisphere and 180 for south?
   That was an addition by Fabrizio to make the EQ parking position correct. I am not sure if it is still required.
3. What is "approach" command used for exactly?
   This is a fairly clever trick by celestron to reduce the influence of the backlash in the relatively cheap mechanics. You make the fast goto to the location which is offset by the small amount from the target, and then you approach the target always from the same direction with "slow goto" which reduces vibrations and cancels all backlash if you approach from the same vector as the tracking will take. It is implemented this way in HC (if I am not mistaken) and in skysafari.
4. What's the parking/cord wrap toggled used for?
   To switch the cordwrap protection in the AZM motor controller and to set the direction it should not cross during gotos. I have noticed that it is not working correctly right now. The CW gets sometimes activated despite being switched off (you noticed this as well). It is probably a simple bug.
5. Any good summary for cord wrap handling? Still not sure about this.
   This is/should be a simple switch - the mechanics of it is handled by the Azm motor controller. There are two controls: Switch On/Off, and direction (angle) of the "uncrossable" position. This position should be opposite your usual observing zone (e.g. in my case it should be N since I have only ESW horizon).
6. MC_SET_NEG_GUIDERATE units appear to be "0.25 arc sec per second".. at least from ASCOM documentation. It appears you tested this experimentally?
   Yes, I did. With many mistakes on the way. There is a short explanation in celestronaux.h. My best experimental value was  1.315 for the TRACK_SCALE. The current TRACK_SCALE comes from the guess (based on measurement) that 1arcmin/min = 1024 units of rate (thus TRACK_SCALE = 60*1024/(2^24/360) = 1.31836). Right now the tracking based on this is just "dead reckoning" without any feedback loop, and it seems to track well enough (with these coefficients) to give good 30-60s expositions in main focus without star movement. Since it is guesswork and experimentation it is absolutely open to discussion. I could not find it documented anywhere. OTOH 0.25"/s would translate to TRACK_SCALE=0.0051 which will be much too low. But this may be subject to consistency of our definitions of rate units. I think the comment in celestronaux.h is actually wrong and should be 1/1024 arcmin/min as a rate unit -> thus TRACK_SCALE = 1024 * 60 / STEPS_PER_DEGREE. Testing this is time-consuming, I did it by measuring time to take the mount to make full rotation with a laser pointer as an indicator and a particular value send as a rate.