Here's a PR to consider viewBox as (additional) fallback. That seemed to be the easiest of the four tasks.

Handy to test: our brand new iconset in core (/core/misc/icons), as none of them has width/height, but all of them have viewBox set. 😉

Edit: PR removed (as not planned)

Interesting finding, why image_get_info doesn't work for newly uploaded svg files:

The first check is to ask the image toolkit, if this is something usable - SVG is not, so there's a second check. That check, down the road, relies on the file extension. And what we have at that point of uploading is something like /tmp/phpABCXYZ without any extension.

I belief, that's a bug. @docwilmot what do you think? Or was it @herbdool, who struggled with that?

I guess, this is relevant for CKEditor, as it uses file_validate_is_image() as upload validator for drag-and-drop upload.

Regarding viewBox, I'm not certain yet if we want to use it for setting the width and height as a fallback. The aspect ratio I can understand, but I'm looking at https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/viewBox and trying to wrap my head around the three example svg with appear the same size but have different viewBox's. The viewBox could be dramatically different, depending on the relationship to the sizes and units of the paths and shapes within it. At least that's how I understand it. Do we want one to be set at width="10" and another at width="100"?

@herbdool re viewBox: I absolutely understand, that you hesitate. Things look even more complicated, when switching to the official spec. We could postpone that viewBox parsing, until someone comes up with a request...

Any opinion re the other three subtasks?

Sounds like the ckeditor drag and drop is important enough to be it's own issue. I don't feel strongly about the others.

I'm guessing pre existing SVG files aren't a big issue. If people were actively uploading bunches of them they were probably installing the svg_image module already.