Neither CoCo nor Retro-Apples are my specific area of expertise - I'll try to answer from a more European viewpoint. Concepts and technical solutions are similar, however.
Basically, all the technologies you describe that allow the adaptation of more memory than the CPU would normally be able to address are, at least in my terminology, denoted under the general term Bank Switching. The implementations of such mechanisms, did, however, differ in terms of memory granularity (that is, size of banks - Which was very often selected as 16kB, which seems kind of appropriate for 64kB address space) and memory flexibility (that is, which bank can be superimposed onto which area in the addressable memory space). The term bank is also kind of unspecific - Some vendors referred to a bank as the source memory area in the larger address space, some others used the term for the target memory area in the CPU's address space.
Some computers also had the limitations that parts of the address space were dedicated to specific purposes like memory-mapped I/O (not on the Z80, typically) and screen memory (the ZX Spectrum 128, for example, always had screen memory fixed at 0x4000 and above). Other computers like the Enterprise could feed the screen more flexibly from selectable memory pages or, like the Cambridge Z88, didn't have screen or other dedicated memory areas in a traditional sense at all.
The Cambridge Z88 is able to address 3.5MB of RAM that is logically segmented into max. 256 16kB pages. Each of those pages can be mapped onto any of four banks of Z80 address space. Granularity: 16kB, Flexibility: full. (Being a kind of early "notebook computer", much of this memory area was normally used for storage in battery-buffered RAM, EPROM or, later, Flash memory)
The Enterprise 128 uses a very similar scheme, 16kB page size, max. addressable memory 4MB, page/bank size 16kB, full flexibility. Like the Z88, the Enterprise provides ROM routines for linear addressing of data and code and moving data and code out and about within the larger address space and thus makes bank switching extremely transparent to the programmer.
The ZX Spectrum 128 ("Toastrack") had a much more limited banking logic. Like the above, it used 16kB pages, and divided its 128kB RAM + 16kb (48k "compatibility" ROM) + 16kB (128k "new" ROM) into 16kB slices. It did, however, have limited flexibility in what pages could be mapped into what bank in the Z80 address space: The lower 16kB bank could only be occupied by either one of the 16kB ROMs (So, that area was dedicated to ROM and made the Toastrack CP/M incapable, unlike later Spectrums), the next bank was fixed for screen memory pages and could only map pages 5 and 7 of the 128kBytes of RAM. Bank 3 was fixed and could not be paged in or out at all, and only Bank 4 could actually receive any of the 8 16kB RAM segments. The original Toastrack ROM did not provide a lot of support for bank switching - You basically have the mechanisms to influence the pages, but beyond that, for example, to move memory contents from one bank to another, you were on your own and had to decide which pages to page in and where.
Later (Amstrad-made) ZX Spectrum models like the +2 and +3 had a more flexible banking scheme.
Computers based on the 6502 or similar CPUs had more challenges with large memory and bank switching than Z80-based computers. The 6502 zero page (or rather, the lower 1kB) is a crucial memory area that cannot be easily moved about in the address space as it holds address information for indirect addressing and other crucial information like the fix-addressed and size-limited CPU stack. Also, 6502 and similar CPUs typically use memory-mapped I/O, so we have another area that needs to fit into the 64k address space. You could easily argue that memory banking had to be more complicated on such a CPU than on the Z80.
The C128 MMU had special mechanisms to relocate this area and always kept the lower 1k mapped to the same RAM. A C128 also had the additional challenge that it needed to orchestrate and accommodate two CPUs - the 8510 and the Z80 with the same memory.
I am not a C128 expert, but understand the following: The C128 had provisions to be able to cope with a maximum amount of 256kB of RAM internally and used sort of fixed memory configurations. While the zero page+ was handled specifically and always paged in from bank 1, you could either have 0x03ff-0xffff all RAM from Bank 0 (one half of the 128k available), or all RAM from Bank 1 (the other half of the 128k), or 16k from Bank 1 and the rest occupied with ROM and either I/O or character ROM. On top of that, the MMU had a common RAM feature, that allowed to partially "override" the RAM configuration in a way that would configure certain memory areas of pre-selected sizes (1k-16k) to always map to Bank 1 memory. All in all, extremely complicated...
With respect to ease of programming, the "fixed page size, fully flexible mapping" approach definitely sounds likethe most simple, easy to understand and program way of doing things on a very low level. Juggling with the C128 MMU and paging registers on a low level doesn't look like fun to me. If, however, the on-board ROM supported you in providing calls and data access routines into the whole memory like the C128 (and, for example, the Enterprise and Z88, where you basically handed in a register triple instead of a register pair to the ROM routines in order to linearly address memory in the 4MB range) did, all of those complications basically became rather transparent to the programmer, so from an applications programmer view, I wouldn't really prefer one over the other.