Wow, this is very intricate and well thought out. Good ideas here.
We have talked about something similar internally. One of our major concerns is exactly what you mentioned- this will make Tulip apps more scalable, but also increase the learning curve and the complexity to get started.
I think the solution needs to be independent of stations, as you suggested. Because, in high mix environments, there are many products with some common processes and other distinct processes. The product is built over multiple stations, so you would still have this problem, but instead across multiple stations.
You would want to turn each app into a “microservice” that operates independently.
Also, different companies may do different parts of the process in other systems.
For example, some companies create their work orders from a Tulip app, and others feed them in from SAP or another system.
I am wondering if it could be done natively in apps without asking users to understand multiple features to get started? There would be an “inputs” section of apps that would allow you to map values to variables when the app is started.
Then, when the app is started, you might have a trigger that is like “Load Data” and allows you to select an app and a recent completion by operator or by timing or by station. Then you would be able to select that previous app’s variables and map them to variables in the current app that were predefined as “inputs”.