I think I get it now. The date meta is stored as a string, so the orderby meta_value sorts the posts as if the meta_value were an ascii string, sorted alphabetically as the chars are found in the ascii table. So Jan 14 2020 will sort before Jan 15 1984.
The proper solution is to store dates in a column formatted for dates, but then you cannot use any post_meta functions, you'd be basically joining in your own terms table.
One thing to try is to set the ORDER BY parameter to be
STR_TO_DATE(wp_ffapostmeta.meta_value, %M %D, %Y) . Of course, if you put that into your arguments array, it'll get butchered by the query parser. It needs to be returned from the 'posts_orderby' filter hook in order to be placed properly in the query. This will work for your site, but for distribution, you need to address the variable table prefixes.
Can I explain posts orderby? Probably, but I'm not sure where to start! Here goes... What you supply as an argument for 'orderby' as a WP_Query or related arguments must be only one of several possible strings because the query parser needs to recognize these strings in order to know what table.column name to place after the ORDER BY command in the actual query. If you supply
'orderby' => 'author' as argument, the parser will generate a portion of the query that looks like
ORDER BY wp_ffaposts.post_author for your site. Other sites will have their correct table prefix specified. The strings recognized by the parser are essentially 'friendly' labels for the actual column names. The parser makes the translation, and in some cases like the meta_value, joins in the needed tables and adds the needed meta_key argument as well. And now perhaps you can see why not providing a meta_key argument causes the query to not work right, the whole
wp_ffapostmeta.meta_key = 'fund_dead' would be missing.
This friendly label thing is why we cannot add a STR_TO_DATE() function to our orderby argument, the parser will not recognize it. It will only see the meta_value portion, and make an ORDER BY command like you see in your 'posts_request' dump. The function we tried to pass would be gone.
Now, finally, the not returning posts with no meta_value. I think if you form a query to simply return all posts with the category, ordered by anything, we can drop in the STR_TO_DATE() argument via filter and things will work... almost. Without a meta_key argument, posts without the meta value will be returned, and those posts will be ordered by the meta_value column, regardless of which key the value is associated to. Not sure what happens to meta values that are not dates, I'm hoping they will not exist.
The other problem is without a meta_key and meta_value argument, the postmeta and term_relationships tables will not even be joined into the query, so the query will fail again. So we need to add the whole join section, from the first INNER JOIN to just before the WHERE, in using the 'posts_join_request' filter. Alternately, we could stick with the whole thing in 'posts_request' and simply inject the correct query right there, all at once. The initial WP_Query arguments would essentially be ignored. The only reason we are using WP_Query instead of $wpdb is so we can use 'the loop'.
As I warned earlier, SQL is not my thing, but this is what I think the query needs to be:
SELECT wp_ffaposts.* FROM wp_ffaposts INNER JOIN wp_ffaterm_relationships ON (wp_ffaposts.ID = wp_ffaterm_relationships.object_id) INNER JOIN wp_ffapostmeta ON (wp_ffaposts.ID = wp_ffapostmeta.post_id) INNER JOIN wp_ffapostmeta AS mt1 ON (wp_ffaposts.ID = mt1.post_id) WHERE 1=1 AND ( wp_ffaterm_relationships.term_taxonomy_id IN (9) ) AND wp_ffaposts.post_type = 'post' AND (wp_ffaposts.post_status = 'publish' OR wp_ffaposts.post_status = 'private') GROUP BY wp_ffaposts.ID ORDER BY STR_TO_DATE(wp_ffapostmeta.meta_value, %M %D, %Y) ASC
I just removed the restriction that a meta_key needs to equal anything and fixed the ORDER BY to treat data as a date. I'm not confident this will work because I don't fully understand how to use term_relationships, only that it is required to tie post IDs to the metadata. But it's probably closer to what you need than anything else we've come up with. Ideally we'd want to order by meta_values that only have a meta_key='fund_dead', without restricting the posts returned. Unfortunately, I don't know how to do that. I'm hoping the query will work for you without that nuance.