The potential concerns with mask-icon is that:

• we should store the site provided color attribute along with the icon. Potentially not a big deal, though the site doesn't specify if that color should be used against light or dark, so we'd need some contrast calculation to return either this color, or white, or black, depending on the ui dark/light theme.
• When using page-icon protocol, it just returns an image, thus we should manipulate the image content to replace the fill before returning it (adding a style that uses @media prefers-color-scheme may suffice). That means we may also need another #ref (apart from the already existing #size) to tell whether the theme is light or dark. We may alternatively do something like setDefaultIconURIPreferredSize, thus add a setDefaultIconURITheme and set it to dark or light when the theme changes, then icons would be served accordingly. If there isn't enough contrast with color, it looks like safari adds a white background, we may either do that or just try to use context-fill.
• I think the problem with SVG was that context-fill would not work on Web provided SVGs. SVG 2 had some kind of support for it, but I don't know what's the state for that. Though since we have to rewrite the icon contents for the reasons above, we may also just replace fill value with context-fill and try if it works in chrome-prividged contexts...

So in the end I think it boils down to store color along with the icon (the database moz_icons table already has a color column for that, currently unused) and manipulate the icon on the way out.