I definitely see the value of this feature.
However, I'm hesitant to add a new flag for this.

Here are the reasons for my hesitation:

1. Keeping the API simple.
   I don't want a proliferation of flags. In fact, I'd like to move in the opposite direction and remove flags: e.g. a) I'd like to remove --completion by having a single completion script that works for all Fire CLIs, and b) possibly we can merge verbose and trace into a single flag.
2. We're also discussing another use of the keyword "debug" for Fire CLIs. This discussion revolves around making the output of Fire CLIs more palatable to non-developer clients of the CLIs, while still keeping the more developer-centric information (filepaths, line numbers, etc) available. This probably more properly falls under the purview of the --verbose flag. We'll want to sort out precisely what verbose + debug will do moving forward (e.g. introducing multiple levels of verbosity) before introducing this pdb/debug feature.
3. A third thing about this feature [in it's current state] that I'm hesitant about is that the --debug flag only does something if there's an error. This means that someone can run a command w/ and w/o the --debug flag, trying to figure out what it does, and will be confused thinking it does nothing.

All of that said, this does seem really useful. Perhaps after I try it out for a few days I'll be persuaded its usefulness outweighs the small cost.

I'm also interested to see how easy it is to do post-mortem debugging w/o modifying fire, e.g. by try/excepting the call to Fire and using pdb in the except block there.