Support was added in SERVER-72687 for $out to write to time-series collection. Therefore, $out can create time-series collection and will overwrite an existing time-series collection if one exists. However, we can extend this functionality, so $out can replace a non time-series collection if a time-series collection exists in the namespace. 

This was initially discussed in SERVER-74061. A few considerations made this ticket outside the scope of SERVER-74061: 

1. We must find a way to rename a view (which is not allowed as of the time writing). This would mean we would either have to change the renameCollection() command, or we would have to drop the view first and then call renameCollection. However, we want to ensure both dropping the view and renaming collection succeed, and that they are done atomically.
2. It is not obvious what collection options would be passed from creating a non time-series collection from a time-series collections. Usually, $out will forward all collection options to the target collection if the source collection exists. However, options have different meanings and different validations from a non time-series collection and a time-series collection. For example, time-series collections can't have temp nor clusteredIndex but non time-series collections can. Time-series collections can have expireAfterSeconds, but non time-series collections must have a clusteredIndex to have expireAfterSeconds. Additionally, what if a change happens to collection options like a new option is created, or an existing option changes how it is implemented in time-series? Would the $out stage need to be changed every time? If there are conflicting collection options how would we decide which to keep and which to remove for the target collection? An alternative solution would be to drop all the collection options and just create a collection from scratch, but that also changes $out current behavior.