I lost a fight with the borrow checker this week, and the humbling part is that I lost because I was wrong. I had a loop that iterated over a vector of items and, on a certain condition, pushed a derived item back onto the same vector. The compiler refused: you can't hold an immutable borrow for the iteration and a mutable borrow to push at the same time. I did the thing everyone does first, which is feel mildly persecuted and reach for a workaround.
My instinct was to clone my way out. But before I did, I sat with the error and asked what it was actually objecting to, rather than how to make it shut up.
It was objecting to the right thing. Pushing onto a vector while iterating it can reallocate the backing buffer, and if it does, any reference into the old buffer is now dangling. In C++ that's a classic iterator-invalidation bug, the kind that works fine in testing and corrupts memory in production when the vector grows at the wrong moment. The borrow checker wasn't being pedantic. It was refusing to let me write a bug I have, in fact, written before in another language and spent an afternoon debugging.
So I collected the new items into a temporary and extended afterwards: three extra lines, no clone of the elements, correct by construction. I "lost", in that I didn't write the loop the way I first imagined. But losing meant the compiler caught at build time a thing I'd otherwise have caught at three in the morning, if at all. I've learned to read a borrow-checker no as a question worth answering before I go hunting for the trick to silence it.