My main concern (having spent about a decade working in MS shops) is that they will try to create a divide between "professional" developers and "hobbyist" developers. Microsoft's fear has always been that their next major competitor will be someone who comes out of their garage. They have always tried to control the programmers so that these programmers will be dependent upon Microsoft. I was literally forced to use Visual Source Safe on more than one occasion because the company I was working for had a contract with MS which prevented us from using any other source code repository (in exchange for discounts on other MS development tools). At the same time, Microsoft did not use VSS internally, because it was horrible. Similarly, we were always playing catch up with APIs. MS would be using them for 18 months or so before any of the rest of use would get any documentation for them (Ha ha! Source code??? Ha ha!)
So my feeling is that this is the embrace part of embrace, extend, extinguish. If I see an effort to rewrite libgit2, or something similar with extensions, then I will be very worried. The reason I can imagine "Don't worry, it will support the git protocol and any hobbyists will be able to make contributions, but if you want a professional interface to Github it is available on reasonable terms (prick your thumb and sign here)" is because I've seen it many times before.
It's not that MS is the only company that pulls this nonsense. Apple is consummately skilled at it: join our fold and have a privileged place in the walled garden.
Free software is intended to level the playing field. As much as MS has improved, I do not believe for an instant that they wish the playing field to be levelled. GitHub, though proprietary originally had no position where it would make sense for them to try to control developer. Now they do.
A really great example of this is the fact that they now give away Visual Studio Professional (rebranded to 'community') for free and even allow unrestricted commercial development/usage for independent studios. I don't recall their definition of independent precisely, but it's something like <= 4 developers, with gross revenue < $1 million/year - the exact definition is similarly fair.
I copied my personal projects to GitLab today and that was very easy to do but I'm not sure what to do about the GitHub version for the one that had a little popularity.
A fork between services becomes more complicate but not so much: git pull from GitLab and git push to GitHub or whatever. Everybody knows how to do it.
Right, one loses the "fork" link between the two repositories but really, who cares? We're writing software for work or for a cause, we shouldn't be playing a game of collecting stars and forks.
For the stars, they presumably did it to get update notifications. I guess they'll get a notification if I update the README, and they can decide what to do about that. I'm making things just a little bit harder for each of these people though.
Forks are even easier to maintain than you're describing. You just need to do a change the url for your upstream. The issue for me is that I have several forks of other peoples projects and in almost every case it's because that's required to make a pull request. For each of these projects that moves, they're multiplying the small effort by the number of people who need to move their forks and/or learn how to make pull requests on the new service.
The forks thing could be tackled. With a notification, something like I forked you. Or a code search engine which is clever enough to detect and link repos.
The user management gubbins, is the normal irritation of user management and access control.
The stars part is already a bit of a horror across all software - not knowing how to gauge the popularity and quality of a project. Nevermind searching for it.
I'm not the biggest user of these silo repos, but I do appreciate that thin barriers to entry, and improved usability or a good usability wrapper, is charming.