a year has gone by and this is still "unconfirmed"?

It looks like less than a quarter of the wishlist items are confirmed.  I don' think this really has any particular meaning or importance - other than perhaps a developer will confirm an item as an unofficial way of increasing the priority.  As has been said on the mailing list, developer time is rather scarce, and the current priority is conversion to Frameworks.  Once that is complete (and there is no timeline yet) there may be more attention to fixing remaining bugs, and then to addressing wishlist items.

Jack, thanks for the reply. Totally understand the time thing.

To All, Just to be clear I wasn't really expecting it to be fixed, I generally take "confirmed" as "someone read this" and hopefully,.... put it on the todo list.

Changing this is a design decision. For me a transaction can have only one payee by definition. Otherwise this are multiple transactions.

Do you have an example for such a transaction? Maybe someone with more knowledge of bookkeeping can help here.

Sure.
Christian hands me a check for services ($500).
Jack hands me a check for services ($1000).
Both of these checks may land into the same category (1099 income, in my case).
I walk into the bank and make a single combined deposit for $1500. This is what my deposit receipt and bank statement will show, and also how I would enter it in my checkbook ledger (KMM).

If I enter it as 2 separate transactions, It becomes correct from the payee perspective, but I lose transaction "correctness" in the checkbook ledger. 

Whereas if I were to leave the payee field blank, and enter the deposit as a split transaction, the entry in the bank ledger would simply read "split transaction" (and it does, by the way) showing the summed total of the splits (as any other split would do), but I would have payee fields where I could assign respective amounts.

I am unfamiliar with "proper" bookkeeping/accounting procedures. I am just a lay person that is self-employed trying to keep his books straight. It just seemed logical to me that if we can have splits, we should be able to do this as well.

This was discovered when I tried reconciling payees against 1099's. I had one that was $600 high and one $600 low. I came to realize that I "credited" an entire deposit to a single payee (having forgotten that the deposit was actually 2 checks). My next thought was "oh, I should split that". And now here I am.

FYI: I changed the heading on the bug to better reflect what I mean

That sounds reasonable to me. Changing it won't be easy but whoever wants to do it has my support. Although the usability of our split system is a couple of decades beyond, so a rework could be interesting anyway.

Interestingly I just ran into this - I had made a deposit earlier in the year, including checks I received from three different sources.  I had a great deal of trouble finding that transaction, since searching by payee obviously didn't work, since the three payees were not mentioned in the transaction.  I only found it by a text search.
I don't know what proper bookkeeping would require here, but I think the real user need is just simplicity in data entry, and having a single split for the bank deposit side, so it matches the bank statement.

The underlying storage design allows a "payee per split" but it is currently not used by the application (split transaction editor).

Are you implying that it may be as simple as just 'enabling' it?

No, unfortunately it is not that easy. Additional code needs to be written in an area that is not maintained anymore. Means, I am currently planning to rewrite it.

If I'm not mistaken, this is now possible in the new ledger, used in any version compiled from git master.  It would be great if the OP could confirm it works for him, and we could close as fixed in 5.2.