Yes, I have a Yaesu FT2D.  I’ll try looking at your suggested radios for guidance on the digital-mode settings. I’ll also try to better check the DN and FM settings on the real radio.

 The FT1 is substantially similar based upon the preexisting FT-1 driver and Yaesu’s manual; FT2D inherits almost everything from FT1. (That looks to be true for the FT-3 as well.)  To get CHIRP working on FT-2D, I also made substantial changes to FT-1 driver because they’re so similar I often only needed to tweak the FT-1 to enable any newer stuff. IIRC, most changes were in character representation. I believe the Yaesu FTM3200 also uses the FT-1D driver.

You’ve asked some questions whose answers are getting me to suss out some flaws in my understanding of how the FT-numeral series works. 

There is (in the radio somewhere, but not apparently in CHIRP-accessible memory) non-variable memory describing SW broadcast, WX, and VHF Marine (NOT GMRS as I’d said before.) They’re called “preset receiver memory channels” in the manual. The channels may be registered into a MEMORY BANK (not into the actual volatile memories, AFAICT) and that information used in the A receiver [FT2DR Instruction Manual (APRS Version), p 69 or <https://www.yaesu.com/downloadFile.cfm?FileID=8930&FileCatID=151&FileName=FT2DR%5FDE%5FOM%5FENG%5FEH060M201.pdf&FileContentType=application%2Fpdf> ] A memory bank channel datum includes an index into the actual memories; high-order bits are used to flag that the data should come from any of the preset receiver memory channels. A memory entry CAN be defined to use, say a WX frequency and modulation mode without any reference to the “preset receiver memory channels”; the radio should automagically prevent transmission, but receiver will work.

During bank operations, the FT-1D driver uses the memory BANK channel data to index into the CHIRP memory. IF a user has placed a preset into a bank memory, then CHIRP used to use the BANK channel index WITH its flag bits set, which is an address way too large for CHIRP to handle; chirp will abort trying to read or write to that address. To “correct” that behavior (yes, I had submitted a ticket, but that was long ago)  I had ANDed out the flags sections, and included a LOG. warn message indicating that CHIRP doesn’t handle this case  correctly. See, e.g., ft1d.py line 503 et seq. _update_bank_with_channel_numbers [I got the source file from a git pull just now; there were no changes to ft1d.py]

Yaesu Memory banks (there are 24) can each contain 100 entries, which are pointers to either the FT1D memory locations or to the “preset receiver memory channels”, depending upon the flag bits. But memory entries need not be registered into any banks AFAICT, nor should CHIRP memory entries be accessed during the processing of presets. I would like to have CHIRP understand, display and set these bank channels to the preset receiver memory channels. It makes sense to have some of these presets usable in a memory bank for use in a special location (repeaters, weather and VHF for scanning, e.g…. indeed that was the use case prompting the ticket submission; the user had manually entered the preset into a bank set up for camping.) CHIRP’s a fine tool for that, and your easy access to the GMRS/FRS data seems to indicate similar considerations.  I think that if I “simply” predefine the data needed, I can fix BANK processing to point to the appropriate “preset receiver memory channels” and avoid memory processing in CHIRP. I’ll have to imagine some way to display a preset memory entry, and to select one if it’s desired. 

I will have to think about this. I fear refactoring the ft1d.py may break some things, and I only have an FT2D, so won’t be able to check everything. So: no decisions yet, bu I’ve got some studying to do!