As per comment from the blog (http://blogs.msdn.com/b/adonet/archive/2013/05/30/ef6-beta-1-available.aspx#10430626):
_Need the entity designer to generate nodes inside .edmx file in exactly the same order they are present in the database (currently a list of entity properties is saved in reverse order in mappings section, also when you update the model from the database schema the ordering is messed up)._
Need to investigate if this is a regression from the previous version.
Comments: We are fixing only the order of Name and Type attributes. With regards to order in the mapping fragment - It appears that there are multiple places where the order of ScalarProperty mapping elements in the edmx can be reversed - so not only MappingFramgment is affected by this. In some cases it was done to avoid creating an edmx that would not validate against the schema(e.g. in mapping to stored procs all properties must come before result binding). It could have been done smarter but given that the version on VS2010 and VS2012 had the same behavior changing it would cause more problems when diffing with the edmx updated with the new designer than leaving it as is. Note that the order of properties in the mapping does not affect functionality - properties in the mapping window seem to be in the correct order and you only see the weird ordering when looking at the edmx directly (i.e. with a text/xml editor).
_Need the entity designer to generate nodes inside .edmx file in exactly the same order they are present in the database (currently a list of entity properties is saved in reverse order in mappings section, also when you update the model from the database schema the ordering is messed up)._
Need to investigate if this is a regression from the previous version.
Comments: We are fixing only the order of Name and Type attributes. With regards to order in the mapping fragment - It appears that there are multiple places where the order of ScalarProperty mapping elements in the edmx can be reversed - so not only MappingFramgment is affected by this. In some cases it was done to avoid creating an edmx that would not validate against the schema(e.g. in mapping to stored procs all properties must come before result binding). It could have been done smarter but given that the version on VS2010 and VS2012 had the same behavior changing it would cause more problems when diffing with the edmx updated with the new designer than leaving it as is. Note that the order of properties in the mapping does not affect functionality - properties in the mapping window seem to be in the correct order and you only see the weird ordering when looking at the edmx directly (i.e. with a text/xml editor).