Some thoughts:
2. Comment edits aren't recorded, so bug trackers don't know if details have been changed. We don't know if there are notifications for edits, so we can't know if a bug requires attention. Could editing comments be turned off project wide?
The lack of editing support in Launchpad was one of the things that bugged me most! It was most annoying when I realized I copied the wrong bug number, linked the wrong commit or just made a typo and knew it would stay wrong forever... I agree that keeping track of changes would be desirable, but even if a history wasn't posible I'd vote in favor of editing anytime!
4. Bug dependence, currently we can't see a way to set one issue as requiring another issue to be completed. But this might just be task lists and we're not used to how this works.
We didn't have that in Launchpad as far as I know and I never missed it. I can't even think of any bugs where this would have been applicable right now. For me this would be a very low priority.
More interesting would be tracking upstream bugs! Does GitLab have this concept? Even if it was only a field like in bugzilla it often would be very helpful to link other bugs (most of the time in other bugtrackers). Launchpad had at least rudimentary support for that ("bug watches" if I remember correctly)
5. We get a lot of wishlist items, so we'd probably want to filter these out. Not sure if issues can be approved before being committed, or if closing many many bug reports is the way to go. If we had the ability to move bugs between projects, then we'd probably set up an inkscape-reporter project to capture public bug reports before moving real ones to the inkscape project itself.
In my opinion wishlist items are just fine as long as they're clearly tagged/prioritized as such. Why would I want to filter them out? They're mostly valid concerns that other users are likely to share and people are likely to search for reports in *one* place (otherwise they might just not search at all and report a new bug right away to let "the project people" handle it themselves).
A splitting of issue and feature tracker will only result in more duplicates that need to be handled and will make it a lot harder to triage reports (often it's not obvious if an issue is a bug or feature, especially for users who just want to report a limitation they're facing).
The only thing that I would ask for (so far I didn't find that functionality) is an "invalid" bug state, that excludes the bug from searches (but only for report's that are in fact invalid and therfore of no use to anybody!).
One additional thing (related to 3. but different and probably much more important for us): What about bugs that affect multiple milestones? As far as I see one can only assign one milestone. If GitLab works as I'm used to from GitHub a commit to master might well close a bug as fixed that still exists in the stable branch. I we have to track this with labels it would be not only a lot of manual work but obviously prone to human error (i.e. bugs that were fixed but never backported to the stable branch).
Regards,
Eduard