For anyone trying to wrap their had around this, like I did, here's what I've figured:

• Vite loads the css and template (as a render function) parts of single file Vue components in separate requests
• The request for /src/components/HelloWorld.vue?vue&type=style&index=0&scoped=true&lang.postcss shows how the css part is loaded in the reproduction project linked in the original issue: Sourcemap failure on Chrome for Vue 2 components with CSS  #9830
• The full response for the above request depends on the Accept header.
• When Accept: "text/css" header is present, Vite simply sends the css extracted from the template + a source map. When devSourcemap: false this sourcemap is like the one from above, with the lots of \n\n\n\n\n\n\n\n\n\n\n\s. It is apparently generated wrong by vite-plugin-vue2 as also indicated here: Source missing in chrome when debugging underfin/vite-plugin-vue2#191
• When Accept: "*/*" header is present, Vite understands that the request is coming from Vite client and should be responded to with a HMR JS file, which includes boilerplate that hooks the file up with the Vite Client, and it contains the original css from the above request in a variable.
• When the plugins are executed against the response before sending it back by loadAndTransform() in transformRequest.ts the plugin vite:css-post comes at the end, which does the HMR wrapping when Accept: "*/*".
• So at this point there is the original CSS with whatever SourceMap is attached to it by any other previous plugins. vite:css-post grabs this css with the SourceMap and puts it inside a JS variable within the HMR boilerplate code and returns this code for further processing by other plugins.
• Usually plugins do changes to the response one after another and those changes are collected in the context under ctx.sourcemapChain as consecutive sourcemaps. At the end these sourcemaps are merged to generate the final sourcemap to be attached to the response.
• However when vite:css-post decided to put the generated css into a JS variable it left the sourcemap in the context. Therefore finally the HMR JS file was returned to the browser with the sourcemap that was generated for the css file.

At this point the issue is two fold:

• Any sourcemaps generated for the css file will not be a proper sourcemap for the HMR JS response, because that is served under an URL that corresponds to the .vue template file, so the browser expects this sourcemap to establish the relationship between the HMR JS file and the original Vue SFC, which it does not.
• The sourcemap generated by vite-plugin-vue2 wrongly maps all lines from the original template as \n causing the browser to render these lines as blanks.

The good thing is however that the css code wrapped into a variable inside the HMR JS response already includes the sourcemap for the CSS, so there is really no need to add the same sourcemap at the end of the HMR JS file too.

This is what the fix relies on: by not only returning the new HMR JS code, but an empty dummy source map as well, it forces the source maps collected in the context so far to be ignored when the source maps are combined. The empty sourcemap masks the others, so no sitemap is generated at the end so the response is sent to the browser as it is, without additional source map attached to the end, what is done for most responses otherwise.

The issue in theory is there both when css.devSourcemap is set to true or false. Only that when it was set to true vite-plugin-vue2 managed to generate a proper sourcemap, which allowed the browser to "see" the original Vue SFC instead of the HMR JS file. But when the css.devSourcemap was false the generated sourcemap masked the non-css lines of the SFC by \n-s, making debugging invisible.

And finally why the sourcemap is not needed at all in the HMR JS file carrying the css payload? Because another file is already loaded by the URL /src/components/HelloWorld.vue which carries the compiled Vue render function and which has a proper source map allowing the browser to display the original SFC source code in the debugger even if the other request does not carry a sourcemap. (Note that the source map for the css is wrapped in a variable, so that cannot be "seen" by the browser until HMR magic does not restores the css code from it and updates the client code with it.

So how come it worked in some browsers and not in others? It is because some browsers ignored the sourcemap from the css request and relied on the other one provided in the other request. After all these requests are for the same file, only differ in query parameters, and there's no standard approach what to do if multiple request claim to provide mappings for a given source. Chrome tries to apply all of them. Firefox processes both sourcemaps and shows two versions of the same source, one based on each. And I assume Safari simply ignores the later one.