It would help to have an example, so I made this one:

(* synthesize *)
module mkTest();

  Reg#(Bool) rg1 <- mkRegU;
  Reg#(Bool) rg2 <- mkRegU;

  rule rl (rg1 && ! rg1);
    rg2 <= False;
  endrule

endmodule

The rule condition can never be true because it has the form x && !x. And if I compile it, I see a message like this:

Warning: "Test.bsv", line 7, column 8: (G0023)
  The condition for rule `rl' is always false. Removing...

BSC runs in a series of stages, so one of the first things I do when debugging is to see what stage things are happening in. I do this with the -v flag, which causes BSC to print the names of the stages as it enters and exits them. The expanded stage is where the design is computed, and after that are a few optimization stages (like transform) that clean up the design before BSC does scheduling analysis. I see that the error message is printed in a stage shortly after expanded and transform (but before schedule) called idroprules:

starting expanded
types OK
expanded done
 elapsed time: CPU 0.00s, real 0.00s

...

starting transform
types OK
transform done
 elapsed time: CPU 0.00s, real 0.00s

...

starting idroprules
Warning: "Test.bsv", line 7, column 8: (G0023)
  The condition for rule `rl' is always false. Removing...
idroprules done
 elapsed time: CPU 0.00s, real 0.00s

...

starting schedule
schedule done
 elapsed time: CPU 0.00s, real 0.00s

BSC can print out the intermediate results of each stage, using -d flags. With -dall you can print all intermediate results, but there's a lot of it, so it can be helpful to print individual stages. The flag -dexpanded can be used to print just the output from the execution stage. You can write it to a file with -dexpanded=out.txt, if you prefer. The flag -help-hidden has some info on these debug/developer flags.

In my example, I can see that the rule condition is still visible in the form x && !x and has not yet been evaluated to False (or zero):

=== expanded:
IModule Test.mkTest­
...
-- imod local defs
__h80 :: Prelude.Bit 1
__h80 = PrimBNot rg1__h79
...
__h74 :: Prelude.Bit 1
__h74 = PrimBAnd rg1__h79 __h80
...
rg1__h79 :: Prelude.Bit 1
rg1__h79 = .Prelude.read ·1 rg1
...
-- imod rules

 RL_rl[IdPRule]:
 "rl":
  when __h74
   ==> .Prelude.write ·1 rg2 0

The syntax for this output is similar to BH. At the bottom, we see the rule rl and its condition is the variable __h74. We can go up to the list of definitions and see where __h74 is defined, and we can follow the definitions to see that the condition is rg1._read && ! rg1._read.

BSC has a stage that inlines definitions, called inline (easily enough), so we can save ourself some effort by dumping after that stage, with -dinline:

 RL_rl[IdPRule]:
 "rl":
  when PrimBAnd rg1__h79 (PrimBNot rg1__h79)
   ==> .Prelude.write ·1 rg2 0

In my example, I see that the transform stage (shortly after this) is where x && !x is reduced to False. I think the only flag that the transform stage has is -opt-bool, but that's off by default already. So I don't think there's a way to prevent the transform stage from applying simple reductions like this. (We might be able to add a flag to turn off the use of the transform stage after expanded, but it might be that some of these cleanups are needed in order to make progress, and turning it off might prevent BSC from getting to the schedule stage or to generating Verilog.)

If you use -dinline (or -dexpanded) on your example, are you able to see a sufficiently unoptimized version of the rule condition that you're interested in?

Hopefully that works! However, it is possible that some conditions might be simplified during the execution of the design. For example, if BSC encounters the code if c then e1 else e2, if the variable c is True, then BSC will replace that with just e1. If you find that the rule condition is already False at the end of the expanded stage, then what you would need is a debugger for the execution, say, to single step through the execution. You can kind of get a print-out of this by using the flags -show-elab-progress and -trace-eval-nf. That second flag will print out the expressions as they are encountered. (It's listed in the -help-hidden message as one of the possible trace flags, but without a description; I know about it because I can see where it's used in the source code.) So, in my example, I see:

[Wed Aug  6 13:40:14 NZST 2025] elab progress: Elaborating rule explicit condition (rl)
walkNF _74

walkNF enter: HWHNF PrimBAnd _79 _80 Nothing

walkNF _79

walkNF enter: HWHNF .Prelude.read ·1 rg1 Just (rg1)

walkNF rg1

walkNF _80

walkNF enter: HWHNF PrimBNot _79 Nothing

walkNF _79

walkNF done: HNF .Prelude.read
      ·1
      rg1 Just (rg1) ([IClock id: ClockId 0 domain: ClockDomain 0 Prelude.Clock CLK 1],
		      [IReset id: ResetId (-1) clock: IClock id: ClockId (-1) domain: ClockDomain (-1) Prelude.Clock 0 0 PrimResetUnassertedVal])

This shows that BSC is evaluating the variable _74 (which eventually becomes the variable __h74 that we saw), and is defined as _79 && _80, and then those variables have definitions, etc.

But hopefully -dinline or -dexpanded will give you what you need?