Undesirable side-effect: Solr Search Integration corrupts core search indexing information

I had a system with the core search set for complete re-indexing and with the 'Number of items to index per cron run:' set to 0 (as recommended by many authors to prevent unnecessary load when using Solr). I then performed full indexing for Solr Search Integration + Solr Attachments. I later decided that for the sake of a demonstration to a client I wanted to indeed also perform core search indexing (to demo core search alongside Solr search), and when I returned to the core search admin page /admin/settings/search I was surprised to find that it claimed that a large percentage of the site had been core indexed:

65% of the site has been indexed. There are 20472 items left to index.

Now as it turns out 20472 is about the number I would expect total would be "to index" for core search. The node table has 20,731 total.

I then activated the Re-indexsite button and it them claimed:

0% of the site has been indexed. There are 59824 items left to index.

Or about 30000 too many.

I confirmed these are just a corruption due to Solr Search Integration. When I turned off first Solr Attachments (disabled the module) I got:

0% of the site has been indexed. There are 40140 items left to index.

Then I switched off Solr Search Integration and got:

0% of the site has been indexed. There are 20456 items left to index.

Which is as expected.

(The search_dataset table has 20,935 total, and is unaffected by whether the Solr modules are enabled or not.)

I'm adamant this one is a bug. The Solr Search Integration and Solr Attachments modules should not corrupt the core search indexing stats, not least when it is intended that they can be used in parallel with core search.

I am concerned also what effect this might have on the core search indexing. How can it know if it is finished ? And what is being indexed if there are thousands of fake nodes in the queue ?