We'd obviously need a true Integer type for that, which might not be so much trivial to implement in their engine now that they've been relying on Floats in all their SQF codebase/api for so many years.

Not at all. It would have the same simplicity as the "mod" function or the "+" operator. It would first check to make sure the type of parameters passed are scalar, most likely flooring the floats before performing the appropriate bit-wise operation and spitting the result back as a float.

Perhaps at its simplest, it would look something like this:

float ArmaScriptingEngine::XOR( float firstParameter, float secondParameter )
{

return (float)( (int)firstParameter ^ (int)secondParameter );

}
I have no clue what Arma's data structures look like so this is just an example of what it may look like:

ArmaObject* ArmaScriptingEngine::XOR( const ArmaObject& firstParameter, const ArmaObject& secondParameter )
{

    if( firstParameter.getType()  != ARMATYPE_SCALAR ||
        secondParameter.getType() != ARMATYPE_SCALAR )
    {
        // Do error stuffs
        return new ArmaScalar( 0.0f );
    }

    return new ArmaScalar( float(int( ArmaCast<ArmaScalar>(firstParameter).getValue() ) ^
        int( ArmaCast<ArmaScalar>(secondParameter).getValue() )) );

}

Of course you can work it that way. That for sure would still be way ahead than continuous floating point modulo 2 then divide by 2 :)

And +1 for that, that's better than nothing.

But the command should clearly state that you are doing your bitwise stuff on the integer conversion of the passed float argument (bitXorAsInt ? intXor ?). Cause who knows, someone might want to use bitwise operation directly on the float bits to retrieve the mantissa or whatever.

So in the end, I personally think that this language missing simple 32bit signed integer is awful, and can only lead to such weird situations + lot of useless performance and precision problem. But the sad thing is, I understand their initial choice for a single SCALAR type, and how it would be hard to introduce integers now given their desire for retro compatibility.

My conclusion : still +1 for your idea via cast, but with explicit indication of this casting via a wise operator name.