Currently Collection constructor and with methods have different handling for collection options. I think they should have identical behavior since a collection object itself is lightweight and doesn't do anything until a method on it is called. Specifically:

.with should accept all of the options that the constructor accepts. I think it's fine to change time series and indexing options, e.g.:

c1 = client['foo']
if c1.count == 0
  c2 = c1.with(clustered_index: true)
  c2.create
end

count doesn't create the collection on the server if it doesn't exist, so the above code appears to be plausible to me.

CHANGEABLE_OPTIONS should, therefore, be expanded to include all options that the constructor is documented to accept.
The constructor (and .with) could possibly filter the options down to CHANGEABLE_OPTIONS. This way the collection's @options would only contain the legal ones. I don't know if this would cause any problems downstream, if yes perhaps don't bother.
Constructor validates that :write and :write_concern have the same value if both are given, .with doesn't. I think .with should have this validation.
.create should have the same validation for :write / :write_concern, and should document accepting :write (deprecated) since it appears to process that option in the method body.
All of .create options should be also accepted by constructor and .with (encrypted_fields, validator) unless this isn't possible for some reason. Alternatively the constructor and .with should be changed to not accept options that apply only to collection creation operation like time_series.