feConvolve matrix bias property premultiplied or not?

The feConvolveMatrix primitive has a bias property whose intent is to 
allow a user to "shift" the zero response. This can be very useful for 
filters where you expect negative values for example (which normally 
would not be representable at all).

However, the feConvolveMatrix primitive is (naturally) defined to 
operate on premultiplied colors, while it is suggested that the bias 
property is simply added to the result of the convolution directly 
(without premultiplication). This would seem to imply that a bias of 0.5 
would correspond to gray if the opacity is 1 and to (transparent) white 
if the opacity is 0.5 (and it would be out of range if the opacity were 
even lower).

I've attached a file that demonstrates the issue, it shows two squares: 
one has a fill of #000 and a fill-opacity of 0.5, the other is opaque 
(the top-left one) with a fill of rgb(75%,75%,75%). The first square has 
a filter applied to it that has a kernel matrix of 1 (identity filter) 
and preserves the alpha channel (for simplicity). The filter has its 
bias set to 0.5. Now, should the the filtered square be transparent gray 
(the same color as the other square, on a white background) or 
transparent white?

Currently Inkscape takes the approach to multiply the bias property with 
the resulting (after adding the bias and clamping) alpha value for each 
pixel (both squares look the same on a white background), Batik simply 
refuses to render the entire file if the bias property is non-zero, 
Firefox seems to skip just the one shape (only the filtered square is 
absent) if the bias property is non-zero and Chrome seems to ignore the 
property altogether.

Are there reasons to add the bias property without premultiplication? If 
so, this seems to go against the only stated use case in the 
specification. If not, can the specification be updated to state that 
the bias property *must* be premultiplied?