Unable to generate the derived image

Fundamentally, this is a valid issue for this module, but one that should be in theory addressed by Drupal core because this module might not be the only one that would enable "svgs" to be handled as image fields.

The underlying issue is that vector images are not supported by the traditional raster-image derivative "image style" logic in Drupal core. If an SVG image URL with a valid itok parameter is requested, then Drupal should:

1) pass-through the original SVG file.
2) allow the SVG that is copied to the image style folder be modified by contrib modules.

The underlying issue is that vector images are not supported by the traditional raster-image derivative "image style" logic in Drupal core. If an SVG image URL with a valid itok parameter is requested, then Drupal should:
1) pass-through the original SVG file.
2) allow the SVG that is copied to the image style folder be modified by contrib modules.

It looks more like a workaround for the issue. I think that it's not a good way to do it because users will expect that all the image style changes will be applied to the image, but it wouldn't. But it could be done as an additional "helper" module for the SVG Image.

users will expect that all the image style changes will be applied to the image,

I guess it depends on the user. I (personally) would definitely not expect Drupal to know how to apply arbitrary raster image manipulations to a vector image.

[changes] could be done as an additional "helper" module for the SVG Image.

If there are even php svg (or binary) libraries that could do this, it would be an incredible amount of work to map all potential raster image manipulation techniques to a vector image. Two common ones: crop with explicit focal point placement, and crop and scale. Now imagine doing this consistently to SVGs that may or may not have height/width/x/y/viewBox attributes. If X and Y attrs happen to be non-zero, things get way more complicated.

Perhaps point #8.2 could be clarified a bit. Let me try again:

1) I suggest that SVGs passthrough raster-image manipulations untouched, but
2) allow other modules to provide their own vector image manipulations (not as helpers to try to apply raster manipulations to vectors, but as separate new manipulations that only apply to vectors). One such manipulation could be converting from vector to raster, and then the subsequent raster manipulations could take effect, but the order of the image style manipulations would be critical for that to work. Other manipulations could be a SVG sanitization task to strip out dangerous XSS or remote links that leak http data. Another one could be to apply specific dimensions, or override fill or stroke color, etc.

By the way, total sidenote... but my current approach and workaround for this is to 301 redirect any image style URLs that contain ".svg?itok=" back to the main image file, to avoid error messages in logs.

This is totally untested, and has not been deployed yet to a production environment but I'm thinking something along these lines:

  # add these lines to docroot/.htaccess inside the <IfModule mod_rewrite.c> section

  # Redirect image derivatives for vector images to source file.
  # https://regex101.com/r/BPeutf/1
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_URI} ^\/sites\/default\/files\/styles\/([^\/]+)\/public\/(.*\.svg\?itok=.*)$ [NC]
  RewriteRule ^sites\/default\/files\/styles\/([^\/]+)\/public\/(.*\.svg\?itok=.*)$$ https://%{HTTP_HOST}/sites/default/files/$2 [L,QSD,R=301]

I may come back to update this code snippet once client approves time to spend on this, or i get some more free time to dive in.