Sorry for not being clear. In fact, the plan for 2.0 is not defined in detail, and we should build consensus on how will the flow package look like in 2.0. My initial idea is to remove all `ford_fulkerson` related functions in 2.0 and thus keep only `preflow_push`, `shortest_augmenting_path` and `edmonds_karp`. In fact this last function (IIUC) is an implementation of the same algorithm that is currently in `ford_fulkerson`, with some differences in the implementation details, for instance `edmonds-karp` follows the new conventions wrt residual networks and flow_dicts. 

Thus, I think that there is no need to keep indefinitely two implementation of the same algorithm. However, for 1.9 I was thinking that it is worth keeping `ford_fulkerson` for backwards compatibility. The `legacy` parameter was intended for making sure that the user code written for 1.8.1 and below (I mean the user code that uses `ford_fulkerson`) will continue working in 1.9, but at the same time, we could be using `ford_fulkerson` internally (tests, maximum_flow, ...) in the same way that we use the new algorithms that you implemented. For that `ford_fulkerson` has to return a residual network.

But as @hagberg pointed out, maybe it is not worth to keep a legacy output for `ford_fulkerson`, it can be confusing and makes the code more complex. My point was that, if we decide to remove `ford_fulkerson` and friends for 2.0 and we don't want it to return the legacy output (flow_value, flow_dict) in 1.9, then it might be easier to remove them now because without the legacy output we are backwards incompatible anyway.