I don't think these issues are inherent of complexity and form factor restrictions. You see, in other parts of the AD UI, you follow the principles we are talking about without any hiccups. Please, Look a the first screen.
In the alignment tab, AD behaves just like any modern software does, if there are at least two objects selected but they don't have a bounding box, then the options are greyed out and the artist can't change values. Greying out gives the user a visual feedback indicating that a requirement (firstly select at least two objects to align and then select them with the move tool) hasn't been fulfilled yet. The artist will realise that the objects are selected with the node tool and once they change to the move tool the options will come to life.
That is the expected system behaviour, but on a side note, perhaps (everything is perhaps until we test with real users) it would be ingenious, if AD went one better and just were a bit smarter to "assume" that if the artist now is opening the transformation studio without having changed from node or any other tool to move, it is because they intended to select the move tool and forgot it and so the system should change the selection from node to move temporarily and then revert back to the users original selection upon the user closing the transformation tab.
But wait a minute, you guys already implemented this smart behaviour elsewhere in AD. Just create an object with no stroke and then go to the colour studio and select a stroke colour and hey presto, AD automatically adds a stroke for the colour the artist chose:
Now go back to the strokeless object and open the colour studio again, don't pick a stroke colour, just try to change the opacity or noise. See what happens now? Nothing happens, much much worse, AD allows the artist to move the slider and plays all the interaction design roles (the button turns blue to show it is being tapped and is active, it slides, the percentage value changes) and then as soon as the artist releases the button it springs back to zero. This illustrates what the issue with Serif products is, it is not complexity but UX and consistency:
In the example above, Serif could have copied one of two behaviours you guys already use in AD: 1) grey out the opacity and noise sliders or 2) add a thick (black?) stroke automatically as one slides the controls. In this specific instance, I would go with option two for several usability reasons: using an initially thick black stroke would warn the artist they still need to pick a colour and select a size; changing a system selected colour is not a big effort and; it is less disruptive. Instead a third behaviour was created, one that unintentionally deceives people and wastes people's effort whilst not giving them any clue of what they need to do.
Now please take a look at the second screen:
By looking at the UI, can you tell which objects are selected to receive the effect? Can you tell which effect I am working on? Can you tell which tool I had selected initially? This is another example of lack of a consistent interaction and visual design language which has nothing to do with software complexity or platform limitations.
Starting from the end, I understand one has to start from somewhere but from the moment you crossed the device threshold, you need to be more mobile-first (at the moment AD is mobile-also but not mobile-first) and refer less to the desktop as your point of reference. As a customer, although I have the desktop version, I only started using Serif products on the iPad and only because unlike Adobe you didn't butcher your vector software and repackaged it into two or three dwarf apps.
Referring to the limitations and complexity, I believe we are well past this kind of argument not only from the moment you yourselves set the example by porting AD and AP to the iPad but also because as I illustrated above, the issues AD has are basic and elementary UX which, I suspect, spring up from not going deep enough into a mobile-first Product Design mentality. Just as an example, in the AD preferences menu, you have an option for "shortcuts" which are all desktop-based, I’d rather have “gestures” with the option to switch two and three fingers gestures with pencil taps and presses instead. How about a pen area? Like an empty circle underneath the studios, where designers who work holding their tablets with one hand or have motor disabilities can tap and each tap emulates a finger pressed on the screen. How about contextual menus that show all my layer functions like Procreate and Autodesk Sketchbook do? This is the sort of mobile-first thinking that is missing in AD.
Yes, I find the consideration for use cases where creatives are using varied digital formats (pixel and vector) to do their art commendable, but that kind of shows that the idea of segregating features and brushes between “personas” based on whether one is using pixels or vectors doesn't work because that is not how creatives work and think (but that is another thread); that is how developers think, and now you find yourself having to create holes in the dividing wall between personas so that the real and most times chaotic creative process may flow.
Finally, perhaps I didn't express this the right way. I never suggested that you took any functionality away, yes allow artists to do vector operations in any mode even in export mode if you will. The problem I am highlighting is that 1) it is a basic principle of software design that if a function is not available for an operation then don't offer it until it is ready, just grey it out until it is available: what is the use of having the corner tool available and displaying its contextual menu when the object selected is a raster object? See third screen:
2) The focal point I am making is that on top of not greying out a function that is not available, AD is duplicating the same function on the same screen and the duplicated function doesn't work like its copy. Once again please see the fourth screen:
The solution is either a) you grey out the duplicated function that doesn't work like its copy or b) you make the duplicated function work equally as its copy as I have illustrated in the beginning of this thread with the fifth screen, which is something AD already correctly does: