Yes, I've used FP's on and off over the decades. I'm a consultant, and we've used or coached many sizing techniques. FP's are just one.

"how can you truly determine the size of a project and compare similar projects"

You can't. Even with FP's, you can't compare "similar" projects.

FP's are not an actual "measurement". They're not lines of source code, or some other real measurement.

FP's are a subjective scoring thing mixed up with some counts. It's a jumping-off point for gauging size. So is a preliminary class model and class feature counts. So are "story points" in user stories.

The "size" of a project does not exist. When -- precisely -- are you measuring the size? First release? After the bugs are "fixed"? After the users stop complaining? Revision 2. The major rewrite for revision 3? After removing the features that were no longer needed? Just before someone decides to replace the package? After all the conversions to a new package?

Does ad-hoc reporting count in the size? What about DB unload reloads as part of technology migration? What about the restore that didn't work and required a special-purpose reload program to recover the lost data? How does all of that figure into the initial estimate of FP's for a "project"?

For estimating purposes, someone wants to know the "total cost". So we scramble around trying to make some kind of development budget.

It rarely actually matters what we say. There's only so many development dollars available. We'll get a share determined politically and it will last about 10 months before the next fiscal year planning rolls around.

We can use FP's to justify our claim that the project will take 8 months. But when we actually start working we discover all of our "assumptions" were false. Users don't cooperate, the technology doesn't work as advertised, regulatory change has made part of the design invalid, and the architect won the lottery and quit. So the 8-month project turned into a 2-year project. Not based on FP's, but based on things that "happened".

How do the FP's serve as a valid, useful measure of all the messy things that really happened along the way?

We don't use function points.

Actually people are surprisingly good when it comes to compare size of a couple of projects. If you asked which of two task is bigger (and how many times bigger) you'd probably get quite good answers. The point where we suck is when itcomes to say how much exactly would take to do one or another task.

That's by the way why story points are so popular - you just say one task costs 3 SP and another 5 SP. You don't say how much time equals 1 story point.

For me the best way to compare (similar) projects is to trust some experienced engineers in the team. When it comes to exact estimates I add some statistics and historical data but relative values like this is twice as big as that should be pretty good if you trust experience.

No. And I have never worked with any team that has used FP measurement.

My Master's Thesis was on FP. I used them a lot for a while. When I got into data warehousing, I stopped using them. I was developing back end ETL and not screens or interfaces. Then I based estimates on experience; but, probably still apply some of the theory of complexity and touch points to come up with an estimate.