Area and Component edit bars should appear and work similarly and consistently. I've had a look at all area types and have defined the way the bars should look depending on whether the area itself is editable or not and depending on how many components an area can and actually does contain.

The two attached images show the result. Compared to the currently implemented solution in 4.5 Sprint III, the following changes have been applied.

No special treatment for single component areas

Single component areas are not treated any different from List areas. From the perspective of a user, this is more consistent. I've also found that a combined area/component edit bar is somewhat difficult to read and leads to many special cases.

In particular, with this solution, there's no need to distinguish between "Edit component" and a possibly existing "Edit area" (nothing prevents us from attaching a dialog to the area) - the buttons can be left with a short command, their location defines what they act upon.

In addition, the component of a single component area is not created using a "Create" button (and removed using a "Remove" button), but is created using "New" and "Delete" just as with any component of a List area. From the perspective of a user, an alternative could be to make a single component area act more like an actual component, but that doesn't solve all problems.

Edit always on right side

In contrast to the current version of Magnolia, on a Component edit bar, "Move" and "Edit" have swapped places with the "Delete" button. This paves the way for Magnolia 5, which will add labels for components as well and will only leave the most common "New" and "Edit" buttons on the bar, while "Move" and the destructive operation "Delete" will be moved away. Moving "Edit" to the right is also more consistent with how Area edit bars are working.

Remark
Areas without any buttons are actually dealt with more closely by SCRUM-494 - they will become even less prominent.