Before the call
The architecture is shaping up at https://drupal.org/node/2107029 , Melissa posted a useful diagram to https://drupal.org/node/2107029#comment-7946793 . So, everything became a plugin. What was addFieldMapping is just an entry in the Migration configuration entity. There's no code or db defined migrations, there's only the Migration configuration entity.
I strongly suggest renaming field to column. It's not used (widely) in Drupal 7 or 8 (unlike property or field).
What's not yet in that issue is that the row is becoming a plugin and what was prepareRow() in the source now will be prepare() on the row plugin. Basically every arrow on the right hand side of the diagram is passing around the row plugin instance: the source plugin returns an array which is passed into the row plugin as configuration. This is what MigrateExecutable gets and then passes it to every process plugin and then finally hands it over to the destination plugin.
For symmetry reasons, we should consider making destination an association array too.
There is no id mapping yet, this needs to be a plugin too to avoid hardwiring migrate into SQL.
What's needed now that people go in and begin to write phpunit tests for the source plugins and then the plugins themselves. We need 1-2 examples up in a week.
Agenda