Code-first. It's a way of defining mappings for O/R mappers by hand-writing entity classes and then hand-writing mapping files (either by using shortcuts like conventions or by a fluent api which allows you to setup the mappings rather quickly) to a database which might not exist yet. I find using that kind of system rather odd. The thing is that O/R mapping is about an abstract entity definition which is realized in both a class definition and a table/view definition, in such a way that there is a mapping definable between the two definitions (class and table) so instances of the abstract entity definition (the data!) can flow between instances of the two definitions: from a table row to an entity class instance and back or vice versa. The work needed to perform that flow of entity instances is done by an O/R mapper.
I've added an additional test result, namely for Linq to Sql with change tracking switched off (in the answers, at the bottom of the article). I also have updated the graph so it's now partitioned: the frameworks which do change tracking and the ones which don't do change tracking are now grouped together. DbDataAdapter with DataTable is added to the change tracking set, as a DataTable does change tracking.