Good questions @ff03k64 
The answers are not short though, there is a lot going on. Updating maps and how they are parsed fits into other projects like a pretty big puzzle, eventually save games will be more compatible and maps uploaded from server. This all feeds into that. The question of whether to YAML or not, is not an easy one.
To start answering, a lot of benefit we get will just be purely from a more expressive structure. XML and YAML are largely equivalent, you can represent just about any XML in YAML and vice versa.
YAML is just less verbose, has no end tags, does not need quotes all over the place, and can be a lot more compact. In particular YAML is good for nested data. In YAML there are three main data types, scalar (a single value), lists, and maps. Maps is a list of key, value pairs, a list is just a listing of values, and a scalar is just a single value. In YAML you can nest these quite easily to have a list of maps which then have as their values more lists.
Let's look at an example, in XML today we have effectively the following map data structure in a 'step' (it's a name and then a series of key value pairs):
<step
name="step1"
delegate="stepDelegate1"
player="player1"
maxRunCount="1"
display="stepDisplay"/>
In YAML:
step:
name: step1
delegate: stepDelegate1
player: player1
maxRunCount: 1
display: stepDisplay
A list in XML is really particularly verbose, eg:
<map>
<territory name="East Prussia"/>
<territory name="Pomerania"/>
<territory name="Saxony"/>
<territory name="Berlin"/>
<territory name="Rhine"/>
In YAML (probably would make sense to rename 'map' to 'territories' here):
map:
- East Prussia
- Pomerania
- Saxony
- Berlin
- Rhine
An example of how we should make the XML more expressive would be the connections. For example today we have something like:
<map>
<territory name="East Prussia"/>
</map>
<connections>
<connection t1="East Prussia" t2="Lithuania"/>
<connection t1="East Prussia" t2="24 Sea Zone"/>
<connection t1="East Prussia" t2="Brest"/>
<connection t1="East Prussia" t2="Danzig"/>
<connection t1="East Prussia" t2="Latvia"/>
As more expressive XML, it would be:
<territories>
<territory name="East Prussia">
<connection to="Lithuania"/>
<connection to="24 Sea Zone"/>
<connection to="Brest"/>
<connection to="Danzig"/>
<connection to="Latvia"/>
</territory>
As YAML:
territories:
- name: East Prussia
connections:
- Lithuania
- 24 Sea Zone
- Brest
- Danzig
- Latvia
There is a short-hand notation in YAML as well where you can define the data in one line, eg:
territories:
- { name: East Prussia, connections: [ "Lithuania", "24 Sea Zone", "Brest" ] }
The most common pitfall in YAML is the indentation, it is significant and items don't line up you'll get an error. For example:
territories:
- name: East Prussia
connections:
- Lithuania
- 24 Sea Zone
- Brest
- Danzig
- Latvia
In the above, lithuania is badly indented, YAML will think that it is another item in the 'territories' list rather than as an item in the connections list. Then 24 Sea Zone will generate an error as it's an illegal start of a list. The prevoius element 'Lithuania' is a scalar value, you can't have a list following a scalar value.
So far as new features only landing in YAML, once YAML is done, i would guess that new map makers would learn in YAML instead of XML. So how hard is it to transition between from XML to YAML?
Given the skill of people having learned XML so well, YAML is not tough. For new map-makers, hard to say, would maybe be slightly more difficult because it is less structured but perhaps about the same.
If you switch to YAML, would that involve any engine changes?
Oh yeah! We'd have to have two completely different parsers. I'm working on some updates that make the engine parsing to be two step. Today it is one step where in one swoop we parse the XML and create game data entities out of it. The updates would make it two step and introduce an intermediary layer that models the data that is in the XML file. The first step in parsing will then be to convert the XML into this intermediary layer. The second step will be to convert the intermediary layer into game entity objects ("game data assembly"). This update will go a long way to either direction as the "game data assembly" will always be the same, the parser of whatever we do will just need to create the same intermediary data and from there it'll be existing code that knows how to assemble it.
With all that said, the difference is going to be whether we have a lot of XML parsing code that says "go here to get this data OR go here to get it", vs having a completely different parsing mechanism. With the intermediary layer either option should not be too bad and hence why some more significant updates are being discussed/proposed. It'll soon be much more feasible to read for example territory connection from either nested 'connection' tags or to read them from their current location.
I am guessing there are plenty of things that could be done cleaner, maybe switching to YAML would be a good time to do that?
The way XML is being read is being cleaned up anyways. The intermediary layer described above fits into other projects to help make game saves easier and more compatible and also make it easier/possible to upload maps from the game itself!
For the XML itself, it's a good time to make it more expressive. Whether we do that in the XML, as YAML, or both is really an open question.
