Another quirk that I'm not sure how to deal with.

bk0011m onboard memory layout is:
Code
    map(0000000, 0037777).ram().share(m_ram[0]);
    
    map(0040000, 0077777).view(m_view1);
    m_view1[6](0040000, 0077777).ram().share(m_ram[0]);
...
    m_view1[5](0040000, 0077777).ram().share(m_ram[7]);

    map(0100000, 0137777).view(m_view2);
    m_view2[6](0100000, 0137777).ram().share(m_ram[0]);
...
    m_view2[5](0100000, 0137777).ram().share(m_ram[7]);
    m_view2[8](0100000, 0137777).rom().region("maincpu", 0);
    m_view2[9](0100000, 0137777).rom().region("maincpu", 040000);
    m_view2[10]; // asserts ROM3 bus signal to access ROM on slot device
    m_view2[11]; // asserts ROM4 bus signal to access ROM on slot device

    map(0140000, 0157777).rom().region("maincpu", 0100000);

    map(0177660, 0177663).rw(m_kbd, FUNC(k1801vp014_device::read), FUNC(k1801vp014_device::write));
... I/O page continues ...

SMK512 is a combo MPI (QBus) device (floppy, ATA bridge, memory expansion), and needs to take over some of the onboard memory ranges some of the time (there are 8 layouts).

Currently I'm using install_rom/ram from within the slot device like so:

m_bus->program_space().install_ram(0100000, 0176777, &m_ram[m_offset]); // layout Hlt10

This deletes the mapping for m_view2, and reinstalling it (after switch to a different layout which does not take over range 0100000) does not work (fatal error "Collision on multiple init_handlers calls").

Technically, when SMK512 takes over range 0100000, it forces the host to "m_view2.select(11)", but I don't see a quick and easy way to access memory on the slot device this way. (Without adding read/write accessors and bus glue to handle ROM4 signal ...)