Looks nice.
An UX issue though: for the menu item set to the default page (language or Global) the "disabled" class vs an opacity set to 0.2 for the button when changing the default to another menu item.
For Global the difference between the yellow star and an empty star is rather clear but not for flags.

I do understand that this class has been traditionally added when clicking on a button does not trigger anything, but we get into a contradiction now where a button which has an action attached to it has a lower opacity. For some language flags they get hardly visible.

Yes i notice that. We could use CSS grayscale filter on the language image button when is not default page, but is not supported in IE (http://caniuse.com/#feat=css-filters).
Example:

Another things i notice from playing with this:

• When you have a menu with english content an a menu item as default english page. If you have some menu items with "All" or "another" language in the same menu, the button to select that menu item as "Global default page" or "Other language default page" will appear.
  Something like this:
  
  Worst is that if you click that buttons it will give two messages
  
  And the previous selected default menu item will loose association and there will exist no default page.
  This seems to be a bug.

• And another thing: Shouldn't, in case of the menus, the default menu item button be an "home" icon? Like the "home" icon in top menu?

Good find!
Yes, we have an issue here when a Menu contains menu items set to ALL as well as some set to a specific content language and a menu item set to a language is set as Home.
In such a menu, the messages are correct when clicking on the Home icon of a menu item set to ALL, but the compulsory default menu item set to ALL in the unused special mainmenu loses its Home/Default setting.

I guess we should first solve this issue.

I also found out the same error when editing such a menu item set to ALL, not only when clicking on the icon in the list.

The error message comes from this line https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_menus/controllers/items.php#L142, which calls https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_menus/models/item.php#L1410

By following it, i think the problem is in this line https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_menus/models/item.php#L1454

This return false (so the error message is displayed and no new home association is made), but before that it removes the current home association. And the problem seems to be there.

Only way to solve this imho is to check if the menutype already contains a home menu item set to a language. It could be in the model or in the library:
See https://github.com/joomla/joomla-cms/blob/staging/libraries/legacy/table/menu.php#L47

@infograf768 a new PR is needed to correct that bug.
I'm not yet comfortable with that part of Joomla code.
Maybe you or other can check that.

Indeed, we need a special PR. I have been looking but I am unsuccessful for now.

Returning to the buttons (the objetive of this PR) :).

IMHO, from a UX point, the buttons should have 4 states:

• Pressed & Enabled: menu item is SET to homepage, and you CAN press it to remove it.
• Pressed & Disabled: menu item is SET to homepage, and you CAN'T press it to remove it.
• Unpressed & Enabled: menu item is NOT SET to homepage, and you CAN press it to set to homepage the menu item.
• Unpressed & Disabled: menu item is NOT SET to homepage, but you CAN'T press it to set to homepage the menu item.

What do you think of having different button styles for this?

This gets very complex and can't be solved in the layout only as we get into too many cases.

I suggest this:
For the menu item set to ALL languages, we do have 2 different icons, so we don't need to use the "disabled" class in all cases.
For menu items set to a specific content language, let's use the "disabled" class only when it is not set to Home. I.e. let's drop de 0.2 opacity.

Did some changes and by using the active class we can get a pushed down button look.

com_templates

com_menus

The one thing i don't like is if the user don't have permissions to change the home item menu the visual is disabled, in other words, we can't visually distinct which button is the default home ...

Any suggestions?

The one thing i don't like is if the user don't have permissions to change the home item menu the visual is disabled, in other words, we can't visually distinct which button is the default home ...

Not good indeed. Why don't you try my suggestion? It just needs to move the "disabled" class and differentiate between menu items set to a content language from those set to ALL

Anything happening with this or is it a dead idea?

is a pendent idea.

When i have time will go to back to it.

What is the status for this?
I like the idea very much and I want to test it and hopefully get it in the core.

@andrepereiradasilva : can you please fix the conflicts..

I have tested this item 🔴 unsuccessfully on bfad325

First issue: A Menu should only contain one default Home

Second issue: After reverting the Patch the Isis/Hator Template/Styles are gone

@icampus Pizza, Bugs &Fun

i'm going to close this to not waste people time.

sorry but i don't have time to pursue this now.