There's nothing being automated, that's the thing.
In the time he wrote those python scripts he could have loaded the bin in ida 20 times.

Automation is detecting the code areas, detecting the global variables.
Not putting a bunch of hardcoded addresses into a .py file.

You guys are pretty spoiled by MED9.1 and Simos18 where everything is the same.
Same flash layout, same globals, same everything.

Try doing that on a slightly larger scale, between different vehicle manufacturers...
You will end up anyway loading the binaries in IDA to find the globals, to find the flash layout etc. And at that point you can just run bindiff directly.

Around MED17/EDC17 is where the Bosch ECU's got all very different, the current approach here is not any better than running bindiff directly from ida pro or Ghidra.

They are universally called globals. On PPC it's usually R2, R13, R14, R15. On ISA just R2 and R13 most of the time. It's up to the compiler where it assigns them.
But you did not do it. You just hardcoded values.
And what happens if you try a non-bosch ECU?
The real answer is statistical analysis. Run an analysis of most used opcodes and you can do a frequency table based on certain bytes that will give you a pretty good idea.
It's not trivial, but doable.
There is a certain pattern I see. You post things on github that have no real value, and then you make a hype post on the forum about it.
I don't understand the reasoning behind it.

Don't get me wrong, it's always good if people work on stuff and share. But "oversharing" stuff that nobody has any use for also does not have a point.

You can always do as little or as much as you want - you don't owe anyone anything.

My remark was more towards the quality of stuff posted. If you make something super specific that is useful in one tiny use case, then it's not going to be very useful for anyone.
There's not really any point posting up code that solves some super specific task, which no one except you most likely has need for.

For example:
For VAG MED9.1 almost every hex/a2l is available in a large damos pack that got leaked.
9.1.1 and others is a different story, but your stuff does not work for it, because it's just a bunch of hardcoded values.
Your topics mostly just say "MED9", which is kinda misleading.

Then we get back to the fact bindiff/symbols in the first place are useful only for those of us who actually modify code.
Everyone else uses WinOLS to quickly transfer the needed maps and be done with it, because that doesn't require a comp-sci background to be successful.
And logging wise my product solves the issue, and again does not require a degree to use. Hell, even those who are perfectly capable of writing similar software use it, because there is zero point in reinventing the wheel.

So if you ask - what to do that is beneficial for others, then the answer is mostly not "some kind of python contraption that requires a degree to use", when there's alternative solutions already available for free or for a small fee.
Doing things that are really beneficial require a significant amount of time, at which point it becomes a full time job. Because for it to be beneficial it has to cover 90% of cases, not a single narrow 1% use case, and the devil is always in the details.

I also left my fulltime software development job to do this. Learned calibration, ICE theory and practice etc. Built up a successful company. Then at some point quit the day-to-day tuner job.
Went back to developing software, but this time for automotive, because there was a niche in the market for datalogging, which I now filled.

John actually has a very valid point here.
Are you looking to make this stuff a full time job?