in the current state of the feature Group Writeback creates a representation of the corresponding Office 365 Group to the local AD.
Originally you cannot manage that groups properties in the local AD, as Azure ADConnect will undo your local changes and will not sync on-prem ADs changes back to Azure AD.
Now as Office 365 Groups are the fundament for Microsoft Teams, this should be changed to that workflow, if Group Writeback is enabled:
a. create the Office 365 Group (or Team) in Azure AD, setting up basic settings and initial owners/members

b. sync it down to my customers local AD by using the Group Writeback feature

c. update the members and owner/managed by properties in local AD

d. sync thar changes back to AzureAD, so Office 365 Groups get updated

In case of a conflict between cloud-managed membership and ownership and the one from the current AAD Connect Sync, the newest change should win.

Additional reference: https://techcommunity.microsoft.com/t5/Office-365-Groups/Sync-Office365-Group-members-from-on-prem-using-Azure-AD-Connect/m-p/194241#M5344

Office365 business lack of support for
* CardDav
* CalDav
* IMAP to GSuite
makes it impossible for me and my clients to use for the following reasons:
it would require maintenance of two sets of calendars, contacts, and emails
many applications (JIRA, etc.) have integrations and Office365 does not and will not likely ever have the same level of developer support.
Thus, you will lose market share unless you add true synchronization features. Additionally, the google sync tool only works with Outlook desktop.

Notes:
* Windows 10 Mail and Calendar support these features so should 365.
* Your 'premium' MAIL service that does not even do what the free Outlook accounts does (IMAP with G Suite works).
* Without a sync to G Suite (paid google accounts) I cannot use Office365, skype, pbx, pstn, or pstn conference.

The changes are additive but if you remove an email address from UnifiedGroup.EmailAddresses, it is not reflected in MsolGroup.ProxyAddresses. This is important for organizations that host multiple domains in the same tenant.

To reproduce:

New-UnifiedGroup -DisplayName "myawesomegroup" -Notes "myawesomegroup" -Alias "myawesomegroup" -EmailAddress "myawesomeness@contoso.onmicrosoft.com" -owner "consultant@contoso.com" -AccessType Public -Verbose

Get-UnifiedGroup myawesomegroup | select *

Set-UnifiedGroup myawesomegroup -PrimarySmtpAddress "myawesomeness@contoso.com"

Set-UnifiedGroup myawesomegroup -PrimarySmtpAddress "yourawesomeness@contoso.onmicrosoft.com"

Set-UnifiedGroup myawesomegroup -EmailAddresses @{remove="SMTP:myawesomeness@contoso.onmicrosoft.com"}

Set-UnifiedGroup myawesomegroup -EmailAddresses @{remove="SMTP:myawesomeness@contoso.com"}

$msolGroup = Get-MsolGroup | Where-Object {$_.DisplayName -eq "myawesomegroup"}

$msolGroup.ProxyAddresses

This shows all the email addresses that have been added. Deleted email addresses still show up here.

These same values (including deleted email addresses) show up in the O365 Admin center:

Groups -> Groups -> myawesomegroup

Group Id : yourawesomeness@contoso.onmicrosoft.com
Aliases: myawesomeness@contoso.onmicrosoft.com, myawesomeness@contoso.com

Unexpected and buggy behavior encountered when permissions are manually set using modern group permissions in a SharePoint site. If you manually assign "Everyone except external users" with "Read" access in a "Private group" SharePoint team site it will remain with those permissions until you make a change in Teams or SharePoint such as adding/removing a member. It appears that making a change in Teams or SharePoint resets default "Private group" permissions for the site and removes "Everyone except external users" from the Visitors group.

Similarly, If you manually set "Everyone except external users" with Read permissions in the Visitors group in a "Public group" SharePoint team site and in Teams or SharePoint add/remove a member it will reset to "Public group" default permissions with "Everyone except external users" in the Members with edit permissions.

Having manually set modern group permissions not stick for "everyone except external users" has major security implications in terms who is allowed/able to modify/access content in an O365 SharePoint site.

since all standard attributes supported by AzureAD do fit the desired naming convention (use some Shorter ones - than long Department / Company terms) we want to use shortcuts in the name of the Group. With this we can get into compliance to the existing GAL Naming convention and Users can directly identify groups belonging to their business Unit. Therefore we need to use the Azure AD extension attributes. The attributes are already filled in the onPrem AD, just waiting to get replicated and supported. This will also allow a lot more flexibility in creation of naming policies, fitting the customers need.
Please Vote for it! Thank you.
best regards
Markus

When an entry is added on a group calendar, it also shows up on each member's personal calendar. Most users do not want to see the group calendar invitation on their personal calendar: 1) because they are already a member of the group, b) not all group activities apply to the every member, and 3) for higher volume calendars, each member is burdened with a lot of time wasted in deleting these entries to clear out their own/personal calendar. SUGGESTION: Add a setting to the Group so that this behavior can be prevented. Selecting multiple calendars (even group calendars) should be a simple and consistent thing for Outlook (local) users to do without additional/unnecessary cleanup work.

Creation of an Office 365 Group will automatically provision a number of O365 services (SP doc library, team site, OneNote, Planner, Calendar, etc). For organizations who are not ready (or able) to leverage certain services, how about providing the ability to control which services can be provisioned for use in groups?

For example, if our organization is only able to leverage an SP doc library and a OneNote, I would be able to configure groups to only make those specific services visible to our end users (items like a team site and Planner would be hidden/unavailable). This would be critical to organizations in more regulated industries, which may hinder their ability to simply turn on and leverage all O365 services as they become available.