While it is standard operating procedure to do so, I think the whole concept is getting long in the tooth and is based on conventions set in the 90’s. Especially with AMA (a fully developed AMA), frame raster and raster type should just be part of the source settings when linking. But having to create a project and manage separately just to set those values is a pain the ass, and project association becomes more problematic, etc. And even when in the project you can change “field motion” anyway, so it just becomes multiple levels of obfuscation.
The same goes for codec choices within the same project. Why have to change project type to transcode to RGB 709 and vice versa? Just pick the one you want and let the computer figure it out.
The same could said for timelines. a project becomes an association of all elements for a given project regardless of sources and delivery timelines.
Now what does come into play as Pat mentions is transcode, but even that can be managed during the transcode selection process with a “preserve source rate or project rate otion” (if projects are still locked to a single rate and raster) or any given target/raster rate.
And while on topic, don’t make auxiliary timecode such a lossy field. When trancoding from one rate to another, there is no reason to lose its original frame rate and ability track it. There are plenty of columns for tracking every kind of timecode rate known. Currently any values being tracked in the AuxTC columns disappear after a transcode.
Michael