Or is there no clear answer and would this be something I'd only be able to figure out by testing against data?
That is the general rule you should always consider when looking at feature engineering (which is what you are proposing), as well as for many architecture choices.
It is very hard to tell in advance what a change to a machine learning system will do for whichever metrics you are interested in. You may have some experience that applies, or find similar experiments online that you can take inspiration from. But you will want to test everything, and should take care to use good practice when evaluating different options - e.g. a cross validation dataset (sometimes called a development dataset).
Would it be redundant/not ideal if I had another feature that was the average of the past 40 opens for example? What about the max/min of the past opens?
One aspect of multi-layer neural networks, is that they can in theory learn useful internal features in the hidden layers from raw data. These internal features are unlikely to be exact copies of mean values or min/max values, or anything else you would construct manually. However, they can be similar enough in end result that manually derived features that you think of will not make much difference.
So you would think that derived features would not be useful in nerual networks. In practice though they can be, because the convergence process to find the best internal features is not perfect. Smart feature engineering can improve the performance of a neural network classification or regression supervised learning. Sometimes you can find "golden" engineered features that relate really well to your target variable, and that boost results significantly.
A couple of things to bear in mind:
A "scattergun" approach of trying a large number of derived features might seem attractive, but there is a risk of overfitting the training data. If you try enough times you may find something that works purely by chance but only for the training data set.
Nonlinear combinations that make conceptual sense given the problem domain can be worth looking at. For instance if you want to predict house prices, and your raw data was house
depth, then floor area
width * depth might be a useful feature.
Feature engineering is still something of an artform. Automated systems using the scattergun approach with filtering are competitive, but domain insight can still win.
If you have vast amounts of data and the CPU time cost is not an issue, you may want to forgo feature engineering due to the theoretical redundancy. It seems possible to make a giant neural network using latest features such as skip connections and batch normalisation, feed it raw (but normalised) data, and press "go" to get a state-of-the-art result. From that perspective, feature engineering is for when you don't have "big data" or deep pockets for heavy processing - for many of us that still means feature engineering is a standard approach on every project.