In general, different CPUs don't use the same bus protocol.
Why not? Sure, different manufacturers defined different bus designs - but more often than not, used them across various CPUs and CPU families.
A 16-bit CPU would not in general be expected to use the same protocol as an 8-bit CPU.
Again, why not? The number of data lines doesn't inherently ask for a different protocol.
For example, the 68000 would not be expected to use the same protocol as the 6809, just because it's a successor made by the same company.
Except it's the other way. The 68k bus is, on purpose, designed to be compatible with the 6800 bus. It follows the same workings, plus extensions for asynchronous operation and half-word access.
DTACK grounded it operates exactly as the 6800 bus, with
AS working as
In fact, designers of a new CPU do need to have a quite good reason to change a bus design in an incompatible manner from its predecessor or other CPUs of the same company. It's never about the CPU alone. The CPU is part of a whole set of components. Changing the way these components interact (aka the bus protocol), would mean that each and every other chip also needs to be modified. This means introducing a dozen or more chips instead of just the CPU. That'll be financial suicide.
When Motorola created the 68000 it was mandatory to make the bus protocol compatible with their huge family of interface chips.
Intel acted similarly with the 8086 (and 286) bus being a compatible implementation of the 8080 bus. Where Motorola offered a few new I/O Chips for the 68k CPU, Intel only provided a new DMA controller. And IBM ignored even that offering and went along with the 8237 and its 64 Ki address range. All because the buses where compatible. A 8259 Interrupt Controller could manage the interrupts for a 8086 just as for a 8080 and a 8237 could drive an 8086 bus the same way as it did for a 8080.
But 8-bit ISA cards made for the IBM PC, were still usable with the 16-bit PC AT (using the 8-bit subset of the bus on the latter).
Because IBM added circuitry to operate that way. The selection for 8 or 16 bit transfers and the according timing are done by external logic, created by IBM. Keep in mind, the PC/PC-AT Bus is not the 8088 bus. It's a separate design by IBM, based on Intel's CPU bus, but not the same.
Did the designers of the 286, specifically go out of their way to stay compatible with the 8088 bus protocol, in order to make this possible?
Not at all. The 80286 bus is exactly the same as the 8086 bus. The main difference is that more address lines are available. Otherwise it's exactly the same bus as with the 8086 - why make a new bus design, and throw away all I/O, when nothing relevant changes?
Implementation-wise, the 80286 came in a package with more pins, so it could support non-multiplexed signals, making latches and bus controllers obsolete (8282 latch and 8288 bus controller - think of these as being integrated into the CPU).
It might be worth to reflect that 'bus' is a quite loose used term, usually denoting nothing more than that it connects several devices for 'some' purpose.
[The following is only in regard to microprocessors; Mainframes and even Minis evolved along different lines]
Here it's about CPU bus and I/O bus - and more so about the way it has been in the 1970s to 1990s. Such classic CPUs expose a CPU bus, intended to integrate several components to work together as a single computing system. They are tied to the philosophy the designer chose. Not least due to the quite limited pin count available, these buses had to handle a multitude of functions, all the way from fast memory and multi processor to slow I/O ports. Most importantly, most of these use cases are about CPU extensions: think DMA or FPU, that may even replace the CPU (DMA) or extend its inner workings (FPU).
I/O buses in contrast did start out as buffered CPU buses (think Altair) maybe with some little additions for arbitration (think Multibus), still following the needs of CPU extension and memory. The PC bus is a great example of an extension that evolved away from the CPU. While the 8 Bit is, much like S100, a rather simple buffered version of the (full decoded) CPU-bus, the AT bus now added
IOCS16 signals not found on the CPU-bus to handle 8 bit cards on a 16 bit CPU, moving it away into a separate system, while still being tied to it and able to serve many of the components a CPU bus is meant for.
Nowadays CPU have next to all the components that were add-ons back then integrated, so the need of CPU buses is more or less an issue of the past. This goes along with way larger packages - in terms of pins at least - offering room for dedicated interfaces instead of a cramped bus.
Now there is usually a dedicated memory bus offered while I/O buses have evolved to be complete different beasts, relieved from the memory-like access and optimized to asynchronous block transmissions (think PCIe).
Thus thinking about classic CPU buses is truly an RC.SE task, isn't it :))