I lived thru that era using Motorola processors and even I can't keep track of who sued who for what despite having been there at the time. I remember subscribing to that newsgroup.

Basically, Hitachi and Motorola, much like land fiber based phone companies, they love and hate each other, often at the same time. On one hand everyone at the cutting edge of tech has to be on the same edge, and certain lucrative .gov contracts require second sources for hardware so they have to cooperate, on the other hand the bean counters see it as an income stream to sue each other for infringement, possibly as a merger strategy gone bad, or just stupidity and arrogance, who knows.

From memory, Hitachi sued Motorola over their 68hc11 microcontroller infringing Hitachi's patents primarily as punishment because Motorola licensed all their pre-'86 CPU technology to Hitachi while Hitachi was of the opinion Motorola falsely post-dated a bunch of hardware features post-'86 literally to F them over when Hitachi marketed their H-8 and H-16 processors. Somehow this lawsuit battle continued into the 90s with Hitachi threatening injunctions on Motorola shipping 68030 processors which were used in early Mac computers, that made the news. In the end, nobody was successful nor made money other than the lawyers.

So in summary, if somebody permits you to second source a design even though they hate you and are in a battle to the legal death with you, and you're like "LOL I can trivially make a 2.0 improved version of this old POS" then depending on how the legal battle is going later on, you might just ship the silicon and kinda not talk about how its a 2.0 improved version that's faster and lower power and new features.

Or in a summary of the summary, the two companies loved/hated each other and there were so many weirdly worded license agreements and open legal cases, that its not entirely clear what was legal or illegal about manufacturing a "2.0" of someone elses processor design.

In this case, my guess would be that the 6309 was marketed as a drop-in compatible replacement for the Motorola 6809. In that case, there is no point advertising other features, because code written for the 6809 won't use them anyway. Rather, you market it on the fact that it's cheaper, uses less power, can be clocked higher, etc. Disclosing all sorts of ISA changes might even scare people off, thinking that the compatibility might be compromised.

So why did they put all those extra features in at all? My guess would be that they had a big buyer, who was in a position to write their own software to make use of those features. This is why you end up with undocumented features in Intel chips today, and the buyers are either big datacentre operators, like Google or Facebook, or government organisations, like the DoD or NSA.

I don't know who such a buyer would be for the 6309, though. It came out in 1982, the same year that Intel released the 286, and Motorola released the 68010 (and National Semiconductor released the NS32016). Also in 1982, Osaka University built what was then the world's fastest supercomputer using Z8001 microprocessors (check out the cooling system in the photo!):

http://museum.ipsj.or.jp/en/computer/other/0013.html

If you were a government agency, wouldn't you rather have a 16 MHz 32-bit 68k than a 5 MHz 8-bit 6309? Or even the 4-10 MHz 16-bit Z8001 that Osaka had used? Of course, if you were a Japanese government agency, you would have to import the 68k or Z-8001 from the USA, whereas the 6309 was made in Japan.

On the other hand, the Motorola 6809 was used for some arcade games, including Defender and Robotron. Maybe Hitachi planned to sell the 6309 to games companies? I assume that games companies controlled their entire software stack, and games always need more performance at an affordable price, so the 6309, as a 6809 but with opportunities to go faster, would have been pretty appealing. The arcade version of Double Dragon used the 6309, although five years after it came out:

https://en.wikipedia.org/wiki/Double_Dragon_(video_game)

I know for a fact that 90s era Liebert brand data center coolers used a 6809 based SCADA board. Presumably running microware OS-9. The business confusion at Hitachi was does management want us to innovate a hardware drop in replacement 2.0 for Liebert's coolers, or do they want us to just ship a second source for replacement parts for Liebert? Using Liebert solely as an example I'm aware of for actual customers.

Speed doesn't really matter to Liebert as its not like data center cooler thermostats are going to be typed on 10x faster by caffeinated humans or fans will spin 10x faster. Although denser code DOES mean more marketable features could be added to the firmware. Of course if you compile for the more advanced 6309 then you no longer have a second source for hardware and theoretically Hitachi could screw you over by charging a lot more than motorola charges for 6809 processors once you're dev team is stuck on the 6309. All I can say for certain is in the end, if you open a 90s era Liebert you'll see a thermostat / early-SCADA PCB with a genuine motorola 6809 on it, so that was THEIR final decision.

90s era Saturn automatic transmissions had a similar issue and they shipped with genuine motorola 68hc11 chips. Again, its not like a 10x faster processor will decrease 0-60 times by ten times, so ...

Generally Hitachi's business strategy WRT CPU licensing seems not to have worked?

It might have been done for product differentiation, or to ensure the designers weren't constrained by needing to be compatible with features that would be burdensome to replicate on future chips. Trivially, if every possible eight-bit value mapped to an opcode (or the first byte of an opcode) the designers were obligated to keep working with that value, because programmers and compiler writers had discovered them all, they would have no space in the opcode table to add new functionality, unless they happened to get lucky and find a byte sequence which was nonsense in the existing chip they could use as a prefix for new encodings. Intel likes prefixes for new x86 opcode encodings, but it does require having a sequence of bytes which can never validly occur in any machine code program for the current generation of chip.

One reason is the extra instructions are an artefact of the decode process - undefined behaviour that just happens to be useful - but woe to you if you rely on them (although I have heard sometimes they are so useful they get publicly supported, I think something like that happened with the z80 and something to do with addressing/address space).

But here, it's weird, especially something like division which presumably isn't cheap to implement and is useful to end users. I don't get it at all.

Not memory addressing, but there is this "special reset" undocumented by Zilog but discovered from a patent http://www.primrosebank.net/computers/z80/z80_special_reset....

I remember this 'scene' was very exciting. Pre-Internet you had to be in the in-crowd (of nerds) on bulletin boards, or at a meet up to ever find out. It felt like a free upgrade to your processor! here's another that's quite good: http://z80.info/zip/z80-documented.pdf

They might be related to the internal workings. A modern x86_64 CPU has hundreds of internal registers. Not all are available to programmers.

This is different. Those internal registers are not accessible at all by software, they are part of the micro-architecture that emulates x86 to the rest of the system, and are actually used. Your modern CPU is like a virtual machine.

That Hitachi CPU however physically had those unused registers as well as that native mode where instructions wouldn't artificially be delayed to be cycle-compatible, but by default behaved like the older and slower model and was only advertised as such.

That doesn't make too much sense first glance, unless there was some glaring bug discovered after production started, or as suggested they feared it would make some more expensive "enterprisey" CPU from another lineup obsolete.

There are undocumented registers that are available to software in x86_64 chips, they just live in MSR space rather than GPR space. Finding them is one of the points of sandsifter.