There's no such thing as "Magit for VSCode", it could be "Magit-like" or "Magit inspired", but never can replace Magit, simply because Magit is not an extension, it's an Emacs package.
Emacs doesn't have "extensions", because every package can be used as a library or radically change the behavior not only Emacs itself but other packages too. Magit's parts been used in other packages - transient.el has evolved into a separate package; magit-section is used in packages like code-review.el, forge, notmuch; magit-git - low-level git interface functions used by packages like diff-hl, git-gutter, etc.; process handling abstraction used by packages that need async process management; etc.
VSCode extensions run in isolation, you can't directly call functions of one extension from another, you can only use what an extension explicitly exposes via its public API (if any). In comparison, Emacs users can freely incorporate Magit's internal commands into their configs, extend them and combine multiple packages seamlessly.
In Emacs, one could write a 5-line function that checks Magit's current branch, queries Projectile for project type, and then calls different Magit commands based on context. In VSCode, something like that would require formal APIs, message passing between extensions, and cooperation from all involved extension authors. In Emacs, you wouldn't even have to save the function on disk before trying it out.
Emacs doesn't have "extensions", because every package can be used as a library or radically change the behavior not only Emacs itself but other packages too. Magit's parts been used in other packages - transient.el has evolved into a separate package; magit-section is used in packages like code-review.el, forge, notmuch; magit-git - low-level git interface functions used by packages like diff-hl, git-gutter, etc.; process handling abstraction used by packages that need async process management; etc.
VSCode extensions run in isolation, you can't directly call functions of one extension from another, you can only use what an extension explicitly exposes via its public API (if any). In comparison, Emacs users can freely incorporate Magit's internal commands into their configs, extend them and combine multiple packages seamlessly.
In Emacs, one could write a 5-line function that checks Magit's current branch, queries Projectile for project type, and then calls different Magit commands based on context. In VSCode, something like that would require formal APIs, message passing between extensions, and cooperation from all involved extension authors. In Emacs, you wouldn't even have to save the function on disk before trying it out.