Interesting scenario. Unary fact types are currently stored in a binarized form which is revalidated on load. If the form doesn't match (including the required boolean data type) then the unary-ness of the fact type is abandoned and you get a binary fact type with a missing role player, as you see.
Relational columns do not have their own data types. The dropdown shown is simply smoke-and-mirrors on the data type corresponding to the underlying value types.
There are three things that could happen here:
Changing the data type of an implicit boolean value (the right-hand-role in a binarized unary fact type) could throw except during reload, where you see the current behavior. This is somewhat tricky because there are legitimate reasons to modify the fact type, such as when inserting a role.
You get the same behavior as on reload (the fact type 'binarizes'). This is ugly because the fact type will now be missing a role player and have errors, which will remove the relational column.
The data type for a boolean should be read-only in the relational view. This should be done regardless of 1 or 2, and--given that this is the only way for the user to change the underlying data type--would completely hide any other issues.
For now, I'll look at making this read-only for a column selection.
As for getting a different data type, look for NCHAR(1) in PROGRAMFILES\Common Files\Neumount\DIL\Transforms\DDILtoOracle.xslt and change it to something else. This simple fix won't get the value range, but is closer to what you want.