Oh wait... Yamaha uses 7-bit addresses, so I guess we'd have to continue to increment after 7F using the third byte..?

No - incrementing the 3rd byte will change the slot number.

We haven't tested but our hypothesis would be that you will only be able to access 128 bytes and that the 'Size 256' is likely a doc error. 

MIDI 1 doesn't allow having the high order bit set within a record. The high order bit is special (e.g. F0, F7). 

The only other 'large' data is the smart morph data and they have their own addresses. For exmaple p.236 for FM-X shows '06 00 10 00' and '06 00 11 00' with single values for add4 and no size.

Yamaha could have used that same 1 byte add4 for '03 4p 0s 00' but apparently didn't.

The difference is that each of the morph data is fixed size but the audio path is variable length. 

Only Yamaha know what the intended design is. Worth an IdeaScale submission, a 'Contact Us' email or both. 

I tested whether there is a documentation error regarding the 256 byte length, and added a wav file with a 156 character name. It was returned correctly in the bulk dump, with 100 null characters to follow - so the synth definitely stores those bytes, and can return them, but short of constructing a bulk request, I can't see how to get or set the value using parameter request / change.

I can't test this without the M.  The parameter change receive (as in Montage M or MODX M on the receiving end) supports multiple 7-bit data bytes so does it work if you stuff 256 data bytes into the parameter change request before the end of SysEx byte?

Still, I wouldn't use this method.  I say this because lots of data (256 bytes) I would prefer to deliver with checksum which only bulk operations allow.  It's fairly close to the same bytes sent except the end of data has the checksum for you to send (and slightly different "command" bytes).  I'm not sure if docs fixed the guidance on forming the checksum but primarily the problem in the past was the communication of what bytes are included (address, length, data, etc).  It's easy to determine by requesting a bulk dump from the instrument and using the checksum it sends as a basis to check what bytes are included.  Otherwise, checksum is done in a fairly standard way for 7-bit data that you can find references for the lower level nuts and bolts.  You probably already have this aced, however, with your previous sw dev.

'The parameter change receive' - that is the problem - sending a SysEx to receive the entire value rather than byte-at-a-time.  

It's an interesting idea to add a checksum byte - my initial approach was indeed to try to send the entire 256 bytes to the parameter address, but Montage responds with the 'Illegal bulk data' modal error on the display. Perhaps adding a checksum byte might make that go away... I shall try and report back.

... unfortunately not. Sending anything other than a single byte to the 03 4p 0s 00 address results in the Ilegal bulk data error.

I think you will find checksums are for 'bulk data' records and not for individual parameters. You can always try though.

P.214/215 don't show any checksum for '(3-5-3) PARAMETER CHANGE' or '(3-5-6) PARAMETER REQUEST'.

Multi byte parameter change doesn't utilize checksum.  I was saying even if I could get that to work I would still send  (keyboard receive) bulk dumps which do utilize checksum.

I've heard back from Yamaha - 03 4p 0s 00 is not supported for parameter request/change, and is only available via bulk data.