i would love to see this happen, but we certainly need to come to some sort of consensus on how the input types correlate to the output value. for instance, would you expect the bits of two different fxp types to get aligned and extended before performing the boolean operation? or would it be more useful if the types were ignored (other than width) and the boolean operation just starts from the least significant bits working up? what would the default output type be?
if labview had an arbitrary width integer (awi), perhaps the proper way to fix this would be to reinterpret cast the fxp values as awis, perform the boolean operations, and then reinterpret cast the output back to the appropriate fxp value.
i'm sure all of this could be controlled via some (smartly chosen) right-click configuration options.
I can't really think of any personal use cases where I would need these operations to work on different fxp types. But I'm hesitant to say, "I don't need it, so lets not include it."
I think the simplest solution would be just ignoring the types and start with LSB working up. A coercion dot can be used if the two types don't match.
I think the best way to apporach it would be to treat the FXPs as being simply binary representation and ignore and type differences beyond the width of the data.