Work was done in
SERVER-25723 to avoid crashing a secondary upon replicating a structurally invalid view definition (i.e. one with unknown fields or incorrect types). We should consider whether it's possible and that we're willing to reject user-initiated writes to the system.views collection. One approach would be to return an error in the following functions that were introduced by Mathias Stearn's work in SERVER-23128. The parsing and validation would be performed prior the catalog operation that actually does the write and should not impact the replication of views.
It is worth mention that issues such as
SERVER-25492 and SERVER-25680 were only identified as a result of a user being able to write directly to the system.views collection. Since we may end up changing the document structure of a view definition in a future release (e.g. by adding a new option), we may want to be able to retain the ability to write directly to the system.views collection for testing purposes.