P: Recognize already imported photos even if they were already deleted from the catalog

Normally when importing from a device no photos will be missed because no date based selection is required - it is sufficient that photos already - and still - imported are detected, and excluded. The issue in this thread arises when photos previously imported, have been deliberately removed since. Hence these are treated the same as if they had never been encountered before.

When a given candidate for import is found not to be currently in the Catalog, LrC can't "know" from this fact alone whether this is a previous import that has since been intentionally removed - or one newly arrived. The desired action will be different, but LrC cannot in this case know which to carry out.

So either the case itself must be changed, or some extra information is needed that LrC could then discriminate by.

The "date approach" seems to me error prone, because

1.) Not every device (e.g. smartphones) has a clear date based folder structure

2.) using a date implies, other later added photos with an old timestamp will be missed.

Case 2 is no usual case but when i get photos submitted from someone else to my smartphone, these "old" timestamped photos will be missed.

It would be really cool to just plugin any device with photo data and import / reject until the dialog is empty ... but without toucing any image twice ... but also don't miss any photo because of a date ...

When you remove images from the LrC Catalog all information about the images is removed the Catalog, 

ideas: besides emptying a card so this does not arise - using Import environment to cull and select wherever possible. That includes selecting or deslecting image subfolders within the camera card. Auto date based folders if the camera can be set to make these, otherwise starting a fresh folder in the camera menu allows you to separate old pictures from new.

Those subfolders become visible by opening up the source location within left side of the import screen and each of these can be highlighted or cleared to control what is in the import batch.  Then within this controlled batch you can further de-select any obvious dud images. Thus LrC expends no further time, disk space or preview generation effort outside of what you do want to import.

Yes, this is an open ended commitment, but it should also not overgrow the database ... i mean its basically just a string list ... at least if there is a unique hash anyway for the photo somehow ... if hash caluclation is expensive and its just for this purpose. Yes, i agree ... might be an impact and not the ideal solution.

Holding the photo file physically but not in the catalogue seems for me no viable solution, since photos that should not be on my storage should not live there for just having more "comfort" on import. A placeholder file could work, but just if its anyhow visible if its really just a placeholder or a real image

However this can be solved: The general idea is to not waste time again on things were decisions were already made before.

It might also be a workflow question in general, but sometimes, especially when many shootings done in quick succession, some of the photos manage it to appear in the catalogue again and again^^

Yes recognising a unique hash could work but these would then need to be all remembered which is an open ended commitment!.

Another option could be to set the archive bit or some such, to denote having been already imported before, within the file system of the camera card. This does requires the ability to write change to that and personally I tend to slide the write-protect tab on SD cards as they go into the card reader so that could not happen.

Another thought: sometimes we Remove a given file without also deleting from disk. In that case perhaps if LrC encounters such a file on attempting a copy re-import, it could (be told to) "take the hint" and neither re-copy this, nor add it back to the Catalog. As a development of that, perhaps a deletion could leave a tiny file behind on disk instead, to (optionally) block future re-addition by import or by folder sync. Such tactics might be sidestepped in the case of renaming during import, though, or DNG conversion during import.