If you have your current config as rollback.xsf, it might not necessarily roll things back. If your config.xsf had "create vlan Data tag 20" and your rollback.xsf doesn't, it will not remove the vlan Data. With that in mind you could do.
You're right. It would reapply the rollback config but wouldn't unconfigure anything.
Check command syntax (e.g. 'cerate veelan Data'), most likely right at the time of being provided by user
Check command validity
To do this right for the full command catalog it would require a lexical, syntactic and semantic analyzers. Additionally we would have to update them with changes in commands. I dont want to be the party popper but its a huge undertaking. Maybe we can leverage the capacity in the OS of the switch to do this somehow.
Engine that will create contrary commands for a rollback, seems to be massive pain in the bottom but least complicated.
Maybe this is more approachable thanks to the configure/unconfigure, add/delete, etc structure, although I think that not always you can substitute one for the other for rollback, like in:
enable sharing 1:1 grouping 1:1 lacp
disable sharing 1:1 grouping 1:1 lacp -> its not correct
I don´t think I have so much free time, but I could collaborate on some parts maybe. If someone from extreme sees this and can push for it with the engineers it can be a feature request. I really think that it should be a integrated feature in exos, but I dont know if it is feasible with scripts or the best way is integration in exos.
Great thread by the way.