Okay...
For what you want to do I'd probably seriously recommend getting a Raspberry Pi or similar to use as a development platform and tackling this from a software angle. I was about to suggest something else but then I noticed that the spec was to use "modern components", and... to be honest, if that's in your desired feature set I don't think *need* an expansion bus based on the memory interface. Strictly speaking, why would you? Many of the sort of devices today you'd interface to a homebrew computer communicate via I2C or SPI. The GPIO connector on a Raspberry PI has pins pre-defined for both sorts of bus, and by adding a demultiplexer onto some of the remaining GPI pins you could add a *lot* of SPI chip selects. (On the far end breaking SPI out into an 8 bit parallel port requires little more than a single chip, so it's a perfectly legitimate way to interface "simple" devices.) And for faster peripherals you have USB 2.0. Yes, it's "only" good for 40-50-ish MB/sec, but that's faster than the memory bus of most 486 class computers, more than good enough for things like sound cards, storage devices, image capture devices, etc, all of which can be had off the shelf for the price of writing a driver. You're not going to do much better than that with a parallel expansion bus unless you make it fast, wide, and *way* too difficult to interface inexpensive homebrew devices to.
(As I alluded to earlier, you can be pretty sloppy when you're playing with one or two Mhz signals like those present on an Apple II bus connector. You just can't do that when you're looking at the speeds involved with the memory bus on a remotely modern system. Again, if we take outperforming USB 2.0 as our baseline specification you're talking about needing to put together a parallel bus that runs faster than NuBus, Microchannel, or EISA, all of which required a big investment in transceiver logic for every card in the system and very careful design to avoid electrical noise on the card edge connectors. The other option would be to run the bus much slower than system memory, doing something like ISA for the slots, but if you do that then you're not gaining much over simply using SPI. )
Strictly speaking, if you're looking at SoC's you're not really talking about building up system "from scratch" anyway. The one reason I could see for pursuing making your own board would be to get the maximum number of GPIO pins. If the point of the system is to do real world I/O and the "expansion bus" is simply a means to that end then if you can get the GPIO pins directly you dispense with the need for an expansion bus. Win!
Anyway. Personally I'd probably suggest, if you do want to go all out with making your own parallel bus system, starting with something more accessible, like a microcontroller or Z-80 based system. For most of what a home experimenter would want to do an ARM system is probably *vast* overkill from a computational standpoint anyway, and it's going to be *much* easier to prototype something that only requires 40 or so wires for a completely non-multiplexed bus.
For what you want to do I'd probably seriously recommend getting a Raspberry Pi or similar to use as a development platform and tackling this from a software angle. I was about to suggest something else but then I noticed that the spec was to use "modern components", and... to be honest, if that's in your desired feature set I don't think *need* an expansion bus based on the memory interface. Strictly speaking, why would you? Many of the sort of devices today you'd interface to a homebrew computer communicate via I2C or SPI. The GPIO connector on a Raspberry PI has pins pre-defined for both sorts of bus, and by adding a demultiplexer onto some of the remaining GPI pins you could add a *lot* of SPI chip selects. (On the far end breaking SPI out into an 8 bit parallel port requires little more than a single chip, so it's a perfectly legitimate way to interface "simple" devices.) And for faster peripherals you have USB 2.0. Yes, it's "only" good for 40-50-ish MB/sec, but that's faster than the memory bus of most 486 class computers, more than good enough for things like sound cards, storage devices, image capture devices, etc, all of which can be had off the shelf for the price of writing a driver. You're not going to do much better than that with a parallel expansion bus unless you make it fast, wide, and *way* too difficult to interface inexpensive homebrew devices to.
(As I alluded to earlier, you can be pretty sloppy when you're playing with one or two Mhz signals like those present on an Apple II bus connector. You just can't do that when you're looking at the speeds involved with the memory bus on a remotely modern system. Again, if we take outperforming USB 2.0 as our baseline specification you're talking about needing to put together a parallel bus that runs faster than NuBus, Microchannel, or EISA, all of which required a big investment in transceiver logic for every card in the system and very careful design to avoid electrical noise on the card edge connectors. The other option would be to run the bus much slower than system memory, doing something like ISA for the slots, but if you do that then you're not gaining much over simply using SPI. )
Strictly speaking, if you're looking at SoC's you're not really talking about building up system "from scratch" anyway. The one reason I could see for pursuing making your own board would be to get the maximum number of GPIO pins. If the point of the system is to do real world I/O and the "expansion bus" is simply a means to that end then if you can get the GPIO pins directly you dispense with the need for an expansion bus. Win!
Anyway. Personally I'd probably suggest, if you do want to go all out with making your own parallel bus system, starting with something more accessible, like a microcontroller or Z-80 based system. For most of what a home experimenter would want to do an ARM system is probably *vast* overkill from a computational standpoint anyway, and it's going to be *much* easier to prototype something that only requires 40 or so wires for a completely non-multiplexed bus.