- If I place a MKT order of BUY 1mi and it gets partial filled as (0.2mi, 0.3mi and 0.5mi, in this order), what would be the getAmount(), getRequestedAmount() and Order state for each of these orders received in ORDER_FILL_OK messages?

- Is it possible that for each of the above partial fills, only the second one was rejected. In other words, will I receive ORDER_FILL_OK, ORDER_FILL_REJECTED and ORDER_FILL_OK messages?

- If a fill is rejected, does the system try to re-fill it automatically again or is it the user's responsibility to re-submit it?

- If I close an order of 1mi and it gets partial filled as (0.2mi, 0.3mi and 0.5mi, in this order), what would be the getAmount(), getRequestedAmount() and Order state for each of these orders received in ORDER_CLOSE_OK?

Market orders don't get filled in such increments. The unfilled amount after the immidiate execution gets rejected. That is
getAmount() = 0.2
getRequestedAmount() = 1.0
IOrder.State = FILLED
See more here:
https://www.dukascopy.com/wiki/index.php ... rket_Order
You will only receive ORDER_FILL_OK.
For market orders there are no resubmission attempts - user has to do it himself. If you wish your order to be resubmitted, you might consider, for instance, limit entry orders, see:
https://www.dukascopy.com/wiki/index.php ... ntry_Order
Amounts are the same as on ORDER_FILL_OK.

Further more if I have placed a bid or an offer order and it gets partial filled, does the platform send any extra messages if more parts are filled?
I just found that the message type ORDER_CHANGED_OK is sent if parts are filled.
Could you please implement a new message which indicates that the order filled fully?

You can unambiguously check this by:

boolean isFullyFilled = Double.compare(order.getAmount(), order.getRequestedAmount()) == 0;

This is uncomfortable. I give you an example as following:

If a programmer wants to set a trailing stop after the order is 100% filled.
So he has to wait until the order is filled by checking within the onMessage(IMessage message) function
1)

message.getType() == IMessage.Type.ORDER_CHANGED_OK 

He cannot use
2)

message.getType() == IMessage.Type.ORDER_FILL_OK

because ORDER_FILL_OK is only sent at the first fill (any size), but never again at partly fillings for the same order.

As your recommendation he can ask if the order is fully filled after the 1) check by

boolean isFullyFilled = Double.compare(order.getAmount(), order.getRequestedAmount()) == 0;

but this will be true at any change to this order after a fully fill. So he has to memorize the fully filled orders, in order to avoid setting trailling stops again and again.

A single ORDER_FULLY_FILLED_OK signal would be much more convenient!

We have updated the diagrams to represent the messages on subsequent fills:
https://www.dukascopy.com/wiki/#Order_state
The request has been registered. But the message type would rather be named ORDER_FULLY_FILLED, since there is no _REJECTED case for this.