Have you considered loading a 2nd file to supplement a gedcom? People who record LC facts don't have to do this, but for those that haven't yet?
Instead of listing people the new report could say, These census ref's were not found on LC, and then list the relatives for people to load at LC?
Yes I considered it and said it would work best if there was the option for users to enter a reference ID against a name as then you have a specific thing to match against. At present most people don't record a census ref in their file (you only recently started doing that as have others), my own file has surprisingly few census refs and most need manual tweaking to be consistent enough to match. Thus for the vast majority of my own records I'd struggle to match anything. Thus it would be a right royal pain to implement.
There is a danger of several things getting conflated here. There are very different and separate issues being discussed intertwined...
1) Who is alive on the 1881 census can we report that?
2) Viewing who has already been entered on the 1881 census
3) Comparing who has been entered on the Lost Cousins website
4) Importing data from Lost Cousins website to update the users tree
5) Automatically adding people from your tree to the Lost Cousins website
1) Yes this is possible this was the very first report added to FTAnalyzer over 8 years ago back in the days when it was a java webservice.
2) Yes this is possible it requires the users tree program to support the GEDCOM standard CENS tag - not all programs or perhaps more accurately not all users do this.
3) This requires lists to be sorted in the same manner on the website and FTAnalyzer this has largely been achieved but could be tweaked to be better. Note this typically relies on having common data in both reports eg: user recording census references in their tree. Or having an individual reference ID on Lost Cousins website as I suggested, either way some tweaks are required to make the sorting similar enough to be usable.
4) This requires everything in 3 and then a whole lot more, it requires an idealised tree where the names are tidied up the dates are fixed and the user has done a lot of manual work, it then requires the users program to actually support importing and merging data and finally and most important of all it requires the user to implicitly trust that importing data won't damage their tree. This one is a dead duck as I fundamentally don't like the idea of tampering with a users tree there is far far too much room for things to go wrong and blame to be attributed.
5) This is different it doesn't require anything more than we have at present, before entering data onto Lost Cousins the user needs certain minimum information. FTAnalyzer could easily create a report of data that the user had yet to enter by REQUIRING census references that completely changes the ball game of 3 above in that it gives a reference to match on. It would then be fairly simple to generate a file that the user could upload to Lost Cousins website and would contain new entries not on the website already. By having requirements before export only entirely valid records would be exported. This would enable users to potentially upload hundreds of new relatives in a few seconds. This would probably require new code on the Lost Cousins site.
So very different subjects that were getting mixed up. The program can already auto search FamilySearch and allow users to see who they can quickly add to Lost Cousins. Adding number 5 as an option and allow users to batch upload people for whom they have a census ref, age, birth location etc. would eliminate at a stroke the major objection people have to using Lost Cousins ie: they've already entered the data why do they have to enter it again.