The task is printed on ticket close. If the the template is merging lines, it assigns the task with unique ID, which is different from the order UID (executing the task print job more than once even generates a different UID for each of the tasks). If the template is not merging lines, it correctly saves the order’s UID. Please check it above.
Dont know whether it is a bug or expected behavior but my issue is solved 
That is expected behavior. Ticket closed is not ideal to get a true orderuid.
I finally understood whats going on here:
If a ticket screen does not merge the orders but the task printer does merge them, there is no way how to keep connection between tasks and orders.
If I order 1 x product A and 2 x product A again before closing the ticket, there are two separate orders with their own UID’s. The task printer creates a single task with 3 x product A. Thats why it creates its own unique UID.
It is a pitty it does not use the ORDER UID at least in the cases where no orders are merged.
Can you not include additional data in the task to link them?
Not really following or done anything similar so don’t know.
Like I said you would need a different order level event to capture this. Ticket level events would not capture them correctly.
It is not an issue with order/ticket level event. If the task printer does not merge orders, everything works well on ticket close. Like I said:
When you order 1 x Product A, then 1 x Product B and then 2 x Product A again, 3 separate orders are saved to the database, each having it’s unique ORDER UID. Only two tasks are created though - 3 x Product A and 1 x Product B. That is why ORDER UID cannot be used to link an order to a task no matter whether it is fired on order added, ticket close or any other event.
So my original idea was fundamentally wrong. I will experiment with identifying the task by Order No. and Product name.
