There are the following problems in the current Python API:
1) some API calls are not synchronous, that is they are not completed by the time API call returns (see example fix [[ https://invent.kde.org/graphics/krita/-/commit/623c5114e009485391be9fbe943a1d9cd4da6bd3 | here ]])
2) some API calls do not initiate updates after they change the node (see example fix [[ https://invent.kde.org/graphics/krita/-/commit/57dbf8a946d022a86855b95f278f1013f29d3148 | here ]])
3) some API calls do not create undo command and basically ignore strokes and stuff that runs in the image atm (see example fix [[ https://invent.kde.org/graphics/krita/-/commit/74dbabc3636fd5a1c18967d9fed105fb2ddaf7b2 | here ]])
4) some API calls return invalid objects, because they cannot get correct info from an asynchronous object (see `Node::mergeDown()`, `d->node` does not belong to the image by the time the action completes, therefore `d->node->prevSibling()` is always null; please note that we cannot just call `d->node->prevSibling()` before starting the action, because 1) `d->node->prevSibling()` will also be removed from the image, 2) the result layer may be put in a different location in some cases (e.g. when some layers are locked or invisible))
Since we want our Python API be fully synchronous and behave "as if the user did it by hand", we need to look through **every** function of Python API and compare to how this action is executed in the normal Krita interface. These actions may either create a stroke, or pass a command to KisProcessingApplicator, or just call a member function, like in some of KisImage methods. After these calls the method should do waitForDone() to make it synchronous.
This change will solve the first three problems. Problem 4) is a bit more complicated and needs some fancy solution, like passing a shared state into a stroke/command.
Ideally, these API changes also needs some kind of unittesting, though I'm not sure how feasible it is.