I also like the change. 

Regarding looping over the facts in a state: usually when I need to loop over facts (in a state, precondition or the goal), I would prefer to get a FactPair instead of a FactProxy. The latter always leads to unwieldy code like "myfunc(fact.get_variable().get_id(), fact.get_value())" instead of the simple "myfunc(fact.var, fact.value)".

I like the change

If we need it, adding something like

for (FactProxy fact : state.facts()) {
    ...
}

where facts() behaves like an iterator in Python doesn't sound too terrible to implement. (Famous last words.)

Currently, states return a FactProxy that is created in the subscript operator and returned. Most receivers immediately call get_value() on the proxy to get to the value. One case where this is not the case queries the state for a facto proxy just to create a VariableProxy from it. A better solution for this case would probably be to ask the state for a TaskProxy and create the VariableProxy from there.

The main complication is that ProxyIterator<State> enables code like
  for (FactProxy fact : state) {...}
This could be handled by another iterator but I found it complicated to avoid the begin/end functions of ProxyIterator even if more specific functions for State iterators are available.

As a preview, here is a diff showing the changes (although this is from a temporary branch in issue348 which might be deleted at some point):
https://github.com/FlorianPommerening/downward/compare/issue348-version2...issue348-debug-no-fact-proxy

To discuss the actual changes we should make a real pull request in the correct branch but it might be worth waiting for issue348 with this.