Read the section about "Byte Selection Logic" in the 68030 manual, it tells you all you need to know. Heck, it even has an example illustrating the bus cycles generated from a scenario involving fetching an odd-byte-aligned 32 bit word from a 16 bit wide RAM. Section 12, page 10 of this manual.
The unsurmountable problem here is the default memory controller ASIC is set up to generate 16 bit aligned addresses for its "private" bus to the onboard RAM (IE, the multiplexed area) for all "true" addresses between 000000 and 9FFFFF. If you double the *width* of the RAM then you need to re-jigger that ASIC so it knows to activate the correct "slice" of RAM for any given address produced by the CPU. (IE, instead of presenting its 10 MegaBYTEs of RAM as 5Mega-16-Bit-ShortWords it instead needs to present itself as 2.5Mega-Longwords... while, again, having it also generate the correct DSACKx signals for a 32 bit memory bank.) If you don't fix this and just hack DSACK then... I suspect what will happen is that every other word written to RAM will end up in a different "half bank" depending on its 16 bit word alignment, which will translate to massive memory corruption. Aaaand, as noted already, even if you do fix *these* problems entirely (both the word alignment and reported transfer sizes) you're still limited to 10MB of RAM, albeit 32 bit wide instead of 16, unless you also figure out a mechanism to map the *other* 2.5 million words of memory space to a non-conflicting area in 24-bit addressing mode and patch the ROM so it knows how switch it back into linear alignment when you switch to 32 bit.
For that last part you *could* potentially use the 63030's built in MMU on the LCII and Classic II but if you want compatibility with the 68020 LC then you'll have to use an address/bank switch built into your new memory controller. And really, that's what this boils down to, needing a new memory controller. Since the VRAM address bus is also generated this thing patching around it externally so it handles DSACKx correctly for wider RAM would be... non-trivial. So far as that goes, it looks like the thing only sits on address lines 0-23 (and 31, which is only used in 32 bit mode to move the peripheral space), so... it actually is physically incapable of handling RAM that would cross the 16MB mark unless you added more external address decoding hardware. (Which, as noted, isn't that big of a deal because you wouldn't be able to use any more than 10MB unless you added bank switching logic too...)
In short, these things are *really* hardwired to be the way they are. If you give up on the "make it wider" thing (that adds too many problems) then... I dunno, *maybe* you could piggyback another set of SIMMs onto the SIMMs that are there and use a blob of external logic to add another 10MB wide 16 bit memory bank running from $01000000 to $019FFFFF? To do that you'd decode A24, cut the chip enable lines that run to the existing RAM, and put an gate on it so if A24 were high the new SIMMs would drive the bus, if not the low set would. You'd still have a 6MB "memory hole" between that bank and the first one that you'd have to program the MMU to close, so it's still not going to work on the original LC, but it's the only way I can see for adding RAM using the original controller that doesn't require completely gutting it and/or using a PDS slot.
The unsurmountable problem here is the default memory controller ASIC is set up to generate 16 bit aligned addresses for its "private" bus to the onboard RAM (IE, the multiplexed area) for all "true" addresses between 000000 and 9FFFFF. If you double the *width* of the RAM then you need to re-jigger that ASIC so it knows to activate the correct "slice" of RAM for any given address produced by the CPU. (IE, instead of presenting its 10 MegaBYTEs of RAM as 5Mega-16-Bit-ShortWords it instead needs to present itself as 2.5Mega-Longwords... while, again, having it also generate the correct DSACKx signals for a 32 bit memory bank.) If you don't fix this and just hack DSACK then... I suspect what will happen is that every other word written to RAM will end up in a different "half bank" depending on its 16 bit word alignment, which will translate to massive memory corruption. Aaaand, as noted already, even if you do fix *these* problems entirely (both the word alignment and reported transfer sizes) you're still limited to 10MB of RAM, albeit 32 bit wide instead of 16, unless you also figure out a mechanism to map the *other* 2.5 million words of memory space to a non-conflicting area in 24-bit addressing mode and patch the ROM so it knows how switch it back into linear alignment when you switch to 32 bit.
For that last part you *could* potentially use the 63030's built in MMU on the LCII and Classic II but if you want compatibility with the 68020 LC then you'll have to use an address/bank switch built into your new memory controller. And really, that's what this boils down to, needing a new memory controller. Since the VRAM address bus is also generated this thing patching around it externally so it handles DSACKx correctly for wider RAM would be... non-trivial. So far as that goes, it looks like the thing only sits on address lines 0-23 (and 31, which is only used in 32 bit mode to move the peripheral space), so... it actually is physically incapable of handling RAM that would cross the 16MB mark unless you added more external address decoding hardware. (Which, as noted, isn't that big of a deal because you wouldn't be able to use any more than 10MB unless you added bank switching logic too...)
In short, these things are *really* hardwired to be the way they are. If you give up on the "make it wider" thing (that adds too many problems) then... I dunno, *maybe* you could piggyback another set of SIMMs onto the SIMMs that are there and use a blob of external logic to add another 10MB wide 16 bit memory bank running from $01000000 to $019FFFFF? To do that you'd decode A24, cut the chip enable lines that run to the existing RAM, and put an gate on it so if A24 were high the new SIMMs would drive the bus, if not the low set would. You'd still have a 6MB "memory hole" between that bank and the first one that you'd have to program the MMU to close, so it's still not going to work on the original LC, but it's the only way I can see for adding RAM using the original controller that doesn't require completely gutting it and/or using a PDS slot.