Thank you @vfdev-5 for the explanation! For now, I have made another commit to revert the changes except for the ones only for ignite.Metric.update.

For future improvements to this issue, I think one way would be to keep the code as-is and add more details for the docstring

- ``update`` must receive output of the form ``(y_pred, y)``.

...to explain how Metric.iteration_completed can help handle the dicts for ignite.Metric.update, and that ignite.Metric.update needs to take (y_pred, y) eventually, like:

- ``update`` must receive output of the form ``(y_pred, y)``. If ``update`` is automatically called by attaching the metric instance to the engine, then ``Metric.iteration_completed`` can convert the output it received to the form ``(y_pred, y)`` by default. If ``update`` is directly called, the output it received must be converted to the form``(y_pred, y)``.

Another way would be to change the code implementation, which I am still considering how to do. One way I could think of is to handle the dicts in the base Metric class instead of in Metric.iteration_completed, so that this statement will still be true:

- ``update`` must receive output of the form ``(y_pred, y)`` or ``{'y_pred': y_pred, 'y': y}``.

and other child classes can either run super(Metric, self).update() to handle the dicts as the base method defines, or ignore and override it if users want to build a custom method. But in this way, ignite.Metric.update will no longer be an abstract method, also I don't think this implementation will look as elegant as the current one does...

For future improvements to this issue, I think one way would be to keep the code as-is and add more details for the docstring

@sallycaoyu I agree on updating docs. Thanks for the updates !