It seems to me that this should be relatively easily extensible to larger RV bays. Possibly realistically-sized ship docks too; the same FTA system should not have trouble moving RVs and ships around.
A few bits of <flags> would obviously have to be undefined or redefined in such contexts, but that doesn't seem like it should pose a major problem.
Format version 3: Additions and changes are marked in bold, removals are marked in red
Prop 16 contains the feature of the vehicles that will use this station, default is 00. (Currently only 00 and 03 are supported)
Prop 17 defines airport movement data and the state machine. It is variable-lengthed and formatted as follows:
<num-pos> is a byte.
<pos-data> is variable-length and repeated <num-data> times.
The <pos-data> corresponding to the hangar(s), if any, must be the first entries in the <pos-data> array, and must correspond to the hangar locations given in prop 19.
It consists of:
<X> <Y> <Z> <flags> <block> (<next-info>)*
<X> and <Y> are words, interpreted as signed integers. They are the X and Y locations of this postion relative to the north corner of the airport. (A tile is 16 (10h) units in each direction.)
<Z> is a byte, as an unsigned integer, giving the height above the ground for this position. One landscaping level is eight units. Aircraft in flight ignore this setting. The default for heliports is 3C and for oil rigs is 36. This is intended to allow placing a helipad on top of a building while still allowing other things at ground level in the same airport.
<flags> is a word, formatted as follows:
The high nine bits are flags:
07 : Movement for current state (possibly) completed; call the state handler for the current state.
08 : Do not clamp speed to taxiing limit.
09 : This is an airplane take-off location.
10 : Aircraft must wait several ticks prior to turning in this position.
11 : This is an airplane landing location.
12 : Force aircraft facing.
13 : Play the airplane brake noise when switching to this position.
14 : This is a helicopter take-off location.
15 : This is a helicopter landing location.
(bits 9..15 map to the AMED_* constants.)
If bit 12 is set, the low three bits specify the direction that the aircraft is turned to face upon reaching this position.
<block> is a byte, indicating which block this position is a part of. Block FF may have any number of aircraft in it at any one time; all others may have at most one at a time. If <block> is the controlling block for a single terminal or helipad, it must have the same value as the <heading> for going to that terminal/helipad. All other block values may be used in any way you desire.
<next-info> is three bytes, in one of the two following formats:
1) <heading> <check-block> <next>
<heading> is a byte.
If heading is in 00..3F, it specifies the number of the terminal this aircraft is going to.
If heading is in 40..7F, the low 6 bits specify the number of the helipad this chopper is going to.
(Yes, airports can have up to 64 each terminals and helipads. This should be sufficient for most purposes.)
The following special values are also available:
80: HANGAR -- Aircraft is going to a hangar, or if at a hangar, enters it for servicing. (Next: TAKEOFF, HELITAKEOFF, TERMn, HELIPADn) 
81: TAKEOFF -- Airplane is headed for the runway for takeoff. (Next: STARTTAKEOFF_*)
82: STARTTAKEOFF -- Airplane is accellerating down the runway; (Next: ENDTAKEOFF) 
83: ENDTAKEOFF -- The aircraft is rising into the air. (Next: none; enters state machine of next airport, with state FLYING)
84: HELITAKEOFF -- Like TAKEOFF, but for choppers. (Next: ENDTAKEOFF)
N/A: FLYING -- The aircraft is in the air, headed for its next order. (Next: LANDING, HELILANDING) 
85: LANDING -- The airplane wants to land. (Next: ENDLANDING)
86: ENDLANDING -- The airplane is rolling down the runway, and will come to a stop at the end. (Next: HANGAR, TERMn) 
87: HELILANDING -- Like LANDING, but for choppers. (Next: HELIENDLANDING)
88: HELIENDLANDING -- Like ENDLANDING, but for choppers. (Next: HANGAR, HELIPADn, TERMn if no helipads) 
89: HELIENDTAKEOFF -- Like ENDTAKEOFF, but for choppers. (Merged with ENDTAKEOFF)
89: STARTTAKEOFF_SMAll -- The version of STARTTAKEOFF used for small planes.
8A: STARTTAKEOFF_LARGE -- The version of STARTTAKEOFF used for large planes.
8B: ENDLANDING_SMALL -- The version of ENDLANDING used for small planes.
8C: ENDLANDING_LARGE -- The version of ENDLANDING used for large planes.
FF: ELSE -- All headings not previously mentioned (also used to mark the last <next-info> entry)
Note that the next information only applies if bit 7 of <flags> is set. If it is clear, the state will not change, and the action associated with that state (eg servicing at the hangar, loading/unloading at a terminal, &c.) will not happen.
 These states have TERMn nexts, and should have terminal selection instructions if multiple terminal groups exist and bit 7 of <flags> is set.
 These states have HELIPADn nexts, and should have helipad selection instructions if multiple helipad groups exist and bit 7 of <flags> is set.
 This is currently the machine exit state. To guard against additional states being added, <next-info> should be be FF FF <cur-pos>, that is "Always return here" or a duplicate entry at the same position with except with a <flags> of 0080h should be added, and that position should have the "Always return here" loop.
 No plane will ever query the state machine in the FLYING state; it will update to LANDING or HELILANDING first, and return to FLYING if it did not find an acceptable landing location.
 These are pseudo-states. No aircraft will ever arrive in either of these states, but they are useful for catching both of STATE_SMALL and STATE_LARGE.
<check-block> is one of
A) A single byte, specifying a block ID. If <check-block> matches <next> -> <block>, no block-reservation checks are performed. Otherwise, both <next> -> <block> and <check-block> must be clear for the plane to proceed. (As in <block>, block FF may contain any number of planes and is therefore always clear.) If both are clear <next> -> <block> is reserved.
B) The byte FE, followed by an FF-terminated list of blocks to check. If all are clear, all are reserved.
C) FE FF -- reserved. Use the single byte <next> -> <block> if you need to specify "check no blocks".
2) <type> <check-block> <group> (Select terminal/helipad from group)
<type> is a byte, either FE (terminal selection) or FD (helipad selection).
The aircraft needs to know what terminal to go to. If <check-block> is clear, select the first free terminal from <group> (terminals are assigned to groups by prop 1A), and then return to this position with the selected heading. If <check-block> is occupied, or no free terminals exist in <group>, continue to the next terminal selection, or wait in this position if no more selections exist.
These may be specified anywhere in the <next-info> list.
These entries are used when provided and bit 7 of flags is set, but are not necessarily useful if the airport has only one group of the relevant type. The *ENDLANDINGs should contain <*ENDLANDING> FF <self-pos> entries to keep the state machine here until it wakes up to the fact that it needs to select a terminal. [mistaken content generated by misinterpretation of the FTA code]
Prop 18 functions as prop 0A and 0F, but copies prop 17 instead.
Prop 19 sets the hangar postion(s). It consists of a byte specifying the number of hangars, and then that many <X> <Y> pairs (both bytes, as unsigned integers) giving the (X,Y) tile offset of each hangar from the north corner of the airport.
Props 1A and 1B set the number of terminals and helipads in each terminal/helipad group, respectively:
<num-in-group> is a byte, and is repeated until a 00 is encountered.
The sum of all <num-in-group> for each property must not exceed 64.
The <heading>s 00..7F (in prop 17) are assigned by these properties; 00/40 to the first item in the first group, 01/41 to the next item in the first group or the first item in the next group, &c.
Prop 1C is a byte which sets the airport type (small/large/heliport) for the purposes of LA build permissions, crash probablilty, and vehicle variable 44. Oil rig (03) exists internally, but may not be set by .grf files.
Prop 1D sets the types of aircraft that can land here:
00 : airplanes only
01 : all (default)
02 : choppers only
Prop 1D is two bytes; the first being the entry position for airplanes, and the second being the entry position for choppers. Must be set properly for both types, even if one type cannot land here. (This airport could be a replacement for an airport where that type could land.)
Prop 1E sets which tiles are animated:
<num-animated-tiles> (<X> <Y>)...
The tile at each (<X>,<Y>) is redrawn every tick. Callback 14 is also called to determine which sprite arrangement to use for this tile.
To control which aircraft types can land at this airport, code the state machine (prop 17) appropriately.
If a distinction between choppers and airships becomes necessary, an additional value will be added to airplane prop 09, and and s/HELI/AIRSHIP/ states will be added.
Properties 08, 09, 0A, 0B, 10, 12, and 13 function as for rail stations, except that bit 1 of prop 0B must be set.
Properties 0C, 0D 0E, 0F, 11, and 14 are meaningless (and ignored) in the context of airports.
Callback 13 works as for rail stations.
Callback 14 works as for rail stations, but may also return 100h to indicate "Build no tile here."
Callback 3C (no action 0 bit) is called whenever a plane in the TAKEOFF or LANDING states selects a new position, and whenever a plane is given an order to this airport.
Variable 10 is formatted as follows:
pp is a position from property 17, the value given as the first byte of prop 1D if an order was added. The other bytes are reserved.
The return value is the length of the longest runway accessible from the given position.
If the plane is in the air and no free runway is long enough, it circles.
If the plane is on the ground and there is no long enough runway accessible from the current position, the plane goes to the hangar and stops.
If the plane is on the ground and there is a long enough runway accessible from the current position, but no entries can be followed (because the runway is too short or <next>'s block is reserved), the plane waits in its current state until a sufficiently long runway clears.
This callback may also be called for position 00 when a plane is checking to see if it can safely visit this airport for servicing.
When called for position 0, a return value of zero also means that this airport has no runways, and that airplanes cannot be built in its hangar(s).
If this callback fails, the value of prop 1C is used to generate a default.
Actions 1..3 work as for rail stations.
Action 4 works as for rail stations for C5xx IDs, and possibly for the C4xx IDs.
The third byte of vehicle variable 44 will have at least the following distinct (and airport-independent) values:
- In hangar
- On a pad
- Taking off
- In flight
The high byte of vehicle variable 44 will contain the <Z> value for the current position.