Given the expressiveness of Perl, I think 150 lines of code per day is at least decent. I've never tried to estimate my own productivity (which is difficult anyway when your project is 85% research work), but I know 100 lines of code is a fair amount of work.

Your key problem is changing requirements. There's really no way estimating your net productivity by looking at the code when the relation between code written and completion percentage gets skewed that way. I think your best bet for that situation is to work with the extreme programming concept of user stories, where a user story is immutable once put down. Any change to it is counted as a new user story, and of course discarded requirements do not result in discarding their count of completed user stories from the total work done.

So if a change of requirements obsoletes two completed user stories, requires changes to another two completed ones, and adds three new stories, this change has incurred a cost of seven user stories. If another change affects a dozen completed user stories and adds a few new ones, you have maybe 15 new user stories. Now if you start piling those up, the client will hopefully start to understand that their "little changes" are actually causing a serious amount of work..

Makeshifts last the longest.