I have found system design interviews specifically 
    much much better at getting signal. I have picked a 
    real problem we had and start people with a simplified 
    architecture diagram of our actual system

To me, this heavily biases towards engineers that have already built or at least designed a similar system to the one you're presenting them.

I believe this will tend to be true even in the ideal case, which is when the interviewer is focused on "is the candidate asking great questions and modifying their proposed design accordingly" rather than "is the candidate coming up with the 'right' solution."

Because, if the candidate his already built/designed a similar system, they will naturally be able to ask better and more focused questions about the design goals and constraints.

     I have tried giving the experiential interviews Casey 
     describes, but I find it quite hard to get signal out of them.

     [...] when candidates say things, you really have no way to 
     understand if what they're saying is true, particularly when 
     internal systems are involved.

Okay, here's where I think I would tend to disagree in a very specific way. First, I would point to the linked interview where Casey conducts a brief mock drilldown interview with the host.

https://youtu.be/gZ2V5VtwrCw?t=2068

The host discussed work he did for Amazon on an event ticket ordering system. Now, I don't think you need to know much about the ticket sales business to think about the challenges here!

The most obvious challenge to me is some sort of distributed lock to ensure the system doesn't don't sell the same seat to multiple people. Another obvious challenge would be handling very bursty traffic patterns, ie an onrush of people and bots when popular event tickets go on sale. Another challenge, brought up by the host, that I wouldn't have thought of is that ticket sales need to avoid "fragmentation" as much as possible. Most people don't want single seats, so you want to sell tickets in a fashion that doesn't leave scattered, "orphaned" single seats that nobody wants to buy.

Those are interesting challenges, and if the interview is an experienced developer, I don't think a candidate could really bullshit through them to a significant degree.

    The candidate may simply parrot things that someone else on 
    the team came up with.

I personally wouldn't care if the ideas originated with the candidate vs. another member of the team. I'd be looking for how well the candidate understood the problem and the solution they implemented, the other solutions considered, the tradeoffs, etc.

    You may end up drilling into a project that is trivial

This feels trivially avoided. If I was the candidate and the interviewer picked a boring project when I had juicier ones, I would just say so. And if I was the interviewer and a candidate told me that, I'd happily pick one of the juicy ones. The point isn't to rigidly lock into a particular project.

    You run into questions of how well a candidate remembers 
    a project, which may not be perfect

This would be expected. Again, I'd be looking big picture here. Approaches considered, tradeoffs made, the "unknown unknowns" that popped up during implementation and how those were handled, etc.