I have a folder in my Library called 'Early Scans' and it contains projects using exactly this material - stuff scanned, sent to me and so on. It doesn't fit the digital camera workflow so it just has to be lumped in there somehow.
Why limit yourself to organising by Projects? They're the basic building block on the Library (every photo must be in a project) but they are also the most inflexible part of the Library. Albums, Smart Albums, Keywording and so onare much more flexible, allow for the same photos to appear in multiple places as needed and so on. In fact - as a family shooter and hobbyist- my projects are in folders by year, and within that year consolidated into meaningful chunks - Spring 05, Italy 05 etc - where Spring gathers all the flotsam and jetsam from the January to May bit, but the Italy one marks a specific and memorable event. But this is just the raw (pardon the pun) material. I'd really, really have to not like you to drag you through all 4,500 shots from that week in Italy.
But... I then use keywords, ratings and Smart Albums to show off the best from that trip, and can use the same system to find the best from all out trips to Italy over many years, and then to just find the best photos I have from anywhere and so on... Family photos are arranged similarly - my in-laws are found by a keyword and so on. I almost never look at projects. It's always done via Albums.
Terrence - thank you for your reply. In your early scans is there any reason to go into the scans and try to redate them since, obviously, the dates will come out as the scan date. Does your workflow or albums or any aperture functions that you use rely on the metadata dates? Or once you have imported into a project that is date labeled or in a specific date named folder is that enough for the hobbyist?
Well I can only comment on my usage, and wouldn't on everyones. For me, what's important about those early images - and these go back to the 1920's in some cases - is the "who" or the "Where" and not the when. So, for instance, I have a Smart Albums based on my parents/parents-in-law rather than on the dates. For me it's enough to know that shot of my Dad was 'early 30's, maybe 32/33' judging by his age in the photo, but for you it might be important to know that it was May 18, 1933. So, I could spend the time and try research the specific date on each scan but I don't feel I need that level of fine detail.
This is true in my camera workflow too. I know I was in Dubrovnik in 2012. So, Project: Dubrovnik 2012. If I really want to know what date(s) in March that was, then that information is in the Exif. But really, for most purposes, that I know it's Spring 2012 is actually enough.
I would add only this: remember that your goal is to create a sack of information that is important to you. (Terence's use, detailed above, illustrates this.) IME, people remember _about_ when a picture was taken, and usually exactly where. Scans, as you're discovering, complicate things. I suggest you consider keeping the "Shoot = Project" usage consistent. Put all the scans from one scanning session in a Project. My reasoning is that you are likely to remember them this way: as a set scanned together, using the same equipment, in one location. Since you remember them that way, you are likely to want to search for, or group them, that way in the future. Then keyword them with people's names, the location where the exposure was made (or use Places), etc. -- and use the keywords (along with Faces and Places, if you use them) to create the Albums and Smart Albums you use for retrieving groups of pictures.
There is no reason not to have Projects such as "Scans pre-2004, not categorized", or "Scans from Uncle Alfred, 1st set".
Your _storage structure_ is about your relationship to the Images in your Library (it is not about what's in the Images).
Your _retrieval structure_ is about what the Images depict.
Keeping these two functions distinct, both in thinking about the Library and in the structures I create, has helped me build serviceable, flexible, robust arrangements with Aperture's tools.