Looking at the wiring, there isn't any significant difference between the two.  Unless you are working in pico seconds.  If one of them works, then you have very marginal signal quality issues.  Have to have good solid ground paths and minimize current loops.
On my K22 part the default reset slew rate (I think was weak driver, fast ) gives the best signals quality.  The rise/fall time is 4ns and that mean I can get by with 4" of tracks that do not have terminations.  In my layout, I always make sure that there are ground return paths to all my signals. I talked a lot about those in my log.

Not a whole lot I can help here unless you have very specific questions.

I will have to re-read all of your projects again, because now I am sure I have missed a lot. Thank you!

try 822 pages of Reference Manual + 58 pages of datasheet - and that's for just one of the chips I use.  Some of my chips have multiple app notes too.  

If you don't mind helping, so that I know I'm looking in the right place; you did mean the Freescale chip datasheet like this: http://www.pjrc.com/teensy/K20P64M72SF1.pdf

It also has a 1377 page reference manual. 

http://www.pjrc.com/teensy/K20P64M72SF1RM.pdf

Having another look at the MAX3421E datasheet again wouldn't hurt either.

Yes.  I have used the K22 chip and now using the KL16 chip.  Both are related to the teensy 3.1 and the LC but not the same family.  I have played with DMA controllers and SPI too.  https://hackaday.io/project/1347-fpga-computereval-board

I didn't bother with the MAX part in my project as I was going to use a OTG chip.  I don't do Arduino libraries however.  I ported RTOS to it.

The manual I read are: K22P48M50SF4.pdf  and I rename the other to K22 Sub-Family Reference Manual (48pins).pdf

Going to need KL16P64M48SF5.pdf,  KL16P80M48SF4RM.pdf for my new project.

Is that for https://hackaday.io/project/5903-sonar-for-the-visually-impaired?

The KL16 is for that project and it is sort of related to the KL26 in the LC - essentially minus the USB.

whoa, now that last pic is quite the header-farm.

You might be on to something, the cross-over of MOSI and MISO could be the problem, two fast signals, coupling... seems plausible. But, surprising with such short-distances. How fast are these things, anyhow? 

Cross-over with the clock would make some sense, but MOSI and MISO, yah'd think they'd both toggle at the same time and have time to settle before the "sample" edge of the clock came through.

I'm pretty certain if you don't cross-over and you have plenty of space between parallel traces (including parallel on opposite sides of a non-planed board), you'd be alright, but if you're doing high-speed stuff, you might be best-off keeping a ground trace inbetween.

I have a hard time thinking these short-distances and data-rates would necessitate things like impedance/length-matching and whatnot, but I dunno. There are a number of "good practices" that'd probably help prevent stuff like that in cases like this, but those are hard to accomplish with point-to-point wiring.

Yahknow, another possibility... SPI has several different "Modes" which actually can seem compatible when wired-up, but might be *right at the edge* of functioning... E.G. if your "Master" is set-up to transition data on the rising-edge of the clock, and the "Slave" expects data to transition on the falling... it might still function in most-cases due to gate-transition-delays... check those SPI modes are matched!

Blue for + and Green for GND... I dunno man, I've only known one other person in the world who's done this... I think *that* is your problem ;) Red and Black, man, red and black!

This might be going too deep... I dunno about your setup, but I have found in some chip-documents the SPI *Configuration* [register-setting] Numbers don't match the de-facto/official SPI *Mode* Numbers... (which, as I recall, number from "SPI Mode 0" to "SPI Mode 3"). In fact, some of those *Configuration* numbers have actually been referred to, in those documents, as "SPI Mode", which makes everything *really* confusing. 

Right now I'm looking at the Atmega8515 datasheet, which shows two different timing-diagrams for two different options, then each of those diagrams show multiple other options... I think, in total, there are at least 8 different SPI configurations possible... several of those will work with each other if *everything* is ideal (matched wire-lengths, fast slew-rates, no noise/cross-talk), but aren't at all spec'd to work together and would fail if any of those ideals weren't met...

If you feel the urge to look into this, I *highly* recommend you check the timing-diagrams on both parts carefully, completely ignoring any "Mode" numbers. And, maybe use that Atmega8515 datasheet's timing-diagrams as a reference to just how many very slight differences might go un-seen if not shown side-by-side.

@esot.eric.wazhung, Fantastic information!!! I must keep this in mind for Kicad. Recap:
1. Never cross MOSI and MISO! (oops!)
2. Put a ground trace in between parallel data lines.
3. Get info on "good practices" for PCBs. Any suggestions?
4.Use Red and Black wires for Vcc & GND so Eric can see. Not just
whatever I had laying around. Good thing I didn't mix up the colors on the same lines, like the 36 Touch Sensor Matrix project, but I should color code stuff more if I expect to get any help at all.

Should the trace lengths for MOSI and MISO on a PCB be the same? What trace width should they be?

As for the software, everything is in Arduino, so the SIP magic is in the libraries. I would have to spend decades to duplicate the work that Paul Stoffregen and Oleg Mazurov put into the software to make this all work (a good reason not to buy ripoff boards.) I am hoping to redirect the output from the USB serial monitor to the slaves. I think someone out there could get all five slaves to connect on the different SPI modes (I think Teensy 3.1 supports 3?), but they wouldn't be playing around with a handful of Arduino boards. If I had the knowledge, I would design a board with one processor and four FTDI chips, but I am just scratching the surface here, and appreciate ANY help.

Thanks again for all your help SPI Master :)

Eh heh... having one of those moments...

I think you could get away with a pretty wonkey PCB design without trouble, as long as all the traces go where expected and nowhere else ;)

Is it possible the crossing-over-wire's insulation just melted?

Sorry for the bombardment of SPI-fears, they don't seem relevant in this case, if you're using libraries designed to work directly with the USB->SPI thing. 

I imagined a two-library setup: e.g. SPI_init(mode); USBshield_init(); as opposed to a single-package which is probably already configured for the right mode...

Datasheet, awesome idea! I actually did read the 67 page datasheet a while ago, but failed to get enough information from it, likely due to lack of formal training. I really should try to go through it again. Most of it assumes I have an oscilloscope :( 

As for the wires touching, there was more space between the wires vertically (think 3D). I will put up a picture of the old set up that didn't work at the end of this log.

I assume this was in response to a message that was deleted...?

Yes, but still applies. I need to read it again.