Functions will be called at specific times (periodical calling like ... "every 60 minutes starting at 08:30" may be considered)

Timezone considerations

The strategy shows the time UTC-like format because it it not tz bounded like the data feeds

pytz doesn't have a notion of local timezone. This poses a small challenged when it comes to accept times which are referring to the actual local time (it may not seem so in real time, but it is in backtesting, in which the datetime reference is marked by the data feeds being backtested)

And even if local time is available, it may not be the wished reference, because the traded data feed can be in a different timezone (some of the use cases show 3 timezones in play: user, data 1 and data 2)

The best possible place to add the scheduling seems to be in the strategy's __init__ method and as such should be a method of Strategy

This doesn't preclude having a global scheduling which could be entered in cerebro to control any strategy.

Collection of numpy/pandas/statsmodel dependent indicators[Done]

The discussions here have given birth to some.

So far none has been added to the package for a good reason: backtrader was meant to be a pure Python package, in the sense that it wouldn't need any external dependencies beyond a regular Python distribution.

(With the exception of matplotlib if plotting was wished)

But at some point in time and even it not based on pandas or numpy arrays, those indicators should make it into the main distribution

Reverting Resampling/Replaying to the original model[Discarded]

The original mode was to create another data feed which would then deliver own bars

At some point in time both features were rewritten as filters manipulating the data stream, which has proven to be prone to quirks, problems and complicated code

It seems sensible to rewrite the functionalities again as originally envisioned

It would be nice to have some way to persist state of the running systems between restarts.

One use case that I am finding difficult to implement is the ability to develop a system which "scales in" to trade positions. The system needs to track the first entry signal and any subsequent trades that may be adding to the position over some specified number of valid signals. This in itself is possible (although has led to some very messy code on my part) but it becomes impossible if the system is restarted after seeing a first signal and subsequent entries as it has lost state of the first trade.

The other use case is to be able to track the system that created a position and be able to allow other systems to trade the same instrument without considering the position of the other system that is trading the same instrument.

The original mode was to create another data feed which would then deliver own bars
At some point in time both features were rewritten as filters manipulating the data stream, which has proven to be prone to quirks, problems and complicated code
It seems sensible to rewrite the functionalities again as originally envisioned

This will not happen. After revision of the many changes done to the current implementation with filters, it doesn't seem sensible to try to backport them to the original data clone implementation.