That's great Mark-Kashman.

A few questions:

1. When do we get to have group members' permission as "contribute" to the site instead of "edit". This is a pain point. Anyone ends up fiddling with, tinkering and changing any page including the home page (either inadvertently by trying out the edit button, or intentionally to put their point). Our users want only the owners to be able to create, edit, or delete site pages (or designated multiple owners). Not every member of the group.
2. Related to above - not sure then how news would work? News is pages. Can news be in a separate page library of its own, so that it's easier to manage permissions. Then members could then create/edit/delete their own news pages and not other's. And this will also help us having a specific content type associated with that library solely for news applying managed metadata which could be separate from regular site pages which may not really require metadata. The whole "promotedstate=2" is hidden anyway.
3. How do we get to assign "visitor" / "read" permission to everyone on a private group's connected site? When we use the "site permissions" right-pane to share "everyone" with "only this site", that is added to the "visitors" group and everything works fine. But, after a few days that disappears and suddenly everyone gets access denied. Our use-case is that although some documents, collaboration and other activities of the group are private, but they may want to keep the site open for all to visit and read. Specific libraries and lists will then override inheritance and be available to only group members. Something like a hybrid between a team-site and a communication-site. 
4. How do we select a particular managed path (teams or sites) for admin created modern sites? Our use-case being, for example IT has its team site for internal collab, but wants to have a communication site with the same name for wider dissemination. So, the path "teams" would make sense for the team site, and path "sites" would make sense for the comms site.
5. How can admins create a modern team site without necessarily being forced to create an O365 Group behind it? Our use-case being, there are several sites that require fluid permission sets with lots of lists and libraries having unique permissions. Nested security groups works best in such cases. Moreover, our users don't want to clog up their Outlook with tens of groups when they don't need to converse at all. Yes, I could go with a classic site, but then it still would be "classic" which at some point in near future may get deprecated. The road-map is clearly modern, isn't it? We want to look ahead, but with flexibility.

Hi Mark-Kashman,

I was under the impression that we'd be able to convert/connect our tenant's root site collection, however I get the following message when using the Set-SPOSiteOffice365Group cmdlet to do so:

Set-SPOSiteOffice365Group : The root site collection for this tenant cannot be connected to an Office 365 Group.

Is connecting the root site collection allowed or am I misunderstanding?

Bruno Aleixo Add me to the list of people who don't understand the rationale, and feel strongly that if this is a design decision it has been implemented very poorly.

If you don't want people to add "everyone" to the Site Visitors group in a Private Group site, then DON'T LET THEM ADD EVERYONE. Allowing people to add that via the UI and then to pull the rug out a couple days later is a terrible user experience.

We have same issue as Abhimanyu Singh . 'Everyone' added to "Group visitors" group disappears from it within few days max. From log it's not clear why, that's only the records what 'everyone' was removed. At the same time if add 'everyone' as domain group  in permissions on the site it works fine.

Thanks for the response Bruno Aleixo 

Everyone except external users being removed from the Members or Visitors is by design.

I don't get it when you say "it is by design". I mean what could be the reason for that? Why after an indeterminate number of days? If it is by design, why not restrict it from happening in the first place so that the users don't get confused?

To workaround this you can..

Is this workaround a supported scenario? Or is it just a hack which can break anytime? (I am talking O365-Group-connected site here, to be clear)

...create a separate sp group with the same permission role

This makes no sense to me. If the three groups "owners", "members", and "visitors" are there already provisioned for the intended use, why is creating a separate group required? This is a problem and extra work. We will need to keep a tab on (and document) which sites an extra group was created and why.

Even the UI makes it very clear, that we are adding members to "site only" (not the O365-Group), and when "read" permission is given they get added to the "visitors" group. See this screenshot:

UI makes it clear that we are adding members to share site only

Now, your response does not make it clear as to why it disappears after a few days? Is a cleanup timer job running somewhere? If it is shared for only the site, then what is the need to clean it up in the first place?

In short, I am not comfortable in creating another SP group just for this, when the appropriate group is already there.

And while we are at it, how can we get "contribute" permissions for members instead of "edit". This is another big gripe of mine with O365-Group-connected sites. I agree, the traditional sites too provision the "edit" permission on the OOTB "members" group, but the big difference is that we can change the permissions on that group without the fear of it getting reverted on its own. But here, with the O365-Group-connected sites, I am wary of changing anything lest a so-called cleanup-routine will run and undo all changes after an indeterminate number of days!

IMHO, documentation is important but not enough. You may not read documentation, you may not read it carefully, you may understand it. Software itself shall alert somehow if you use wrong function. If 'everyone' shall not work it shall not work from the moment when you try to add it.

What is the current scenario - you add 'everyone'. Test behaviour with few users, it could take couple of days, everything works fine. On third day you deploy the change and announce to the company.  On next day after that someone requests access, you check - 'everyone' disappeared. Add it again since you know it worked and you know 'everyone' works for a long while on other sites (yes, on couple of our sites it works probably for months). After that you are asking other admins and owners who the hell removed 'everyone'. Nobody. In a while cycle repeats. Finally you check the log and see what the system removed 'everyone'. Start checking all your settings, nothing. Open the ticket? - but if they don't know the answer they ask to do all the tests they know and reinstall everything from scratch, plus it takes a lot of time. Let check on TechComm. Uh, I'm not alone and that is by design...

Bruno Aleixothanks for the update, but that doesn't actually provide much of an answer. Is there any explanation as to purpose behind this? What is the justification/rationale? Why would Microsoft care if we add everyone to a visitor group? And why does it work within Microsoft but not for the rest of us? Because this is the precise scenario used for the Intrazone podcast site - It's a private group-connected SharePoint team site that is open to all of Microsoft. Read the comments, when I asked Mark-Kashman about it, his answer was to Invite people > "Share site only" with "everyone except external" as this will add them to the member group.

Is it worth bothering to put something on SharePoint User Voice? 

Also, doesn't this defeat the purpose of the modern Site Permissions option? The whole point was for users to be able to see who a site is shared with to allow them to make good choices about what to post there. Now I have a site that APPEARS to be limited to the members, but in reality is open to everyone. How is this a good thing?

Hi, thanks for the news.

What about the subsites?

Where do they go when we connect the top level site collection to a new office group ?

Thanks