I think I have everything that I hoped to for a .9.4 release already submitted.

As for .10, I am in favor of using that release to begin phasing out deprecations, most notably the matrix class.

Another possible future change to consider for that time frame is merging StateSpace and LinearIOSystem classes. Are there any reasons to keep them separate aside from the effort to refactor the code? There is also the matter of what the resulting class should be called.

What's needed for a 1.0 release? Here are two possible features that come to mind that may be worth considering:

1. Time delays
2. Refactoring the code to separate plotting from computation enough to enable a plot-free version of python control as suggested in Lightweight version of python-control #808, which would be helped by New plotting paradigm #645

As long as we are talking about architecture, I had a question about the use of the dictionaries input_index and output_index. Is there any chance we could get away with a simplification in which signal names were stored entirely in input_labels and output_labels, which are lists of signal names? The location in the list could encode the index of the signal. To find the index associated with a name/label, you would use the syntax sys.input_labels.index('u') rather than sys.input_index['u'] -- a few more characters, but fewer fields to keep around and keep in sync. But I really don't know all the ways these are used -- especially as we move toward multivariable interconnect -- so I may be missing something.

There are not actually two separate class variables. Instead input_labels (and the others) is a property that just returns input_labels.keys(). So no syncing issues (and you can use sys.input_labels.index('u') if you like -:).

Regarding system classes, here is what we have now:

I think we can do the following:

• Collapse NamedIOSystem and InputOutputSystem into a single class (probably InputOutputSystem)
• Collapse LinearIOSystem and StateSpace into a single class (probably StateSpace)
• All other classes (LTI, FRD, NonlinearIOSystem, InterconnectedSystem, LinearICSystem) remain

This would give us something like this (focusing just on the I/O system classes and leaving out FRD):

That makes sense! - I agree with your suggestions for how to collapse the class hierarchy.

Also - sounds good in regards to putting off multivar interconnect to the next release. Might be nice to have some time to experiment with it once it is merged because of the aforementioned changes.

Hi, I am sorry that I can not participate much in the discussions recently. I am in preparation of my upcoming PhD defense.

As far as I can tell, all suggestions look good to me, though.

Closing this issue since 0.9.4 has now been released. Discussion on 0.10 is moved to #917.