My understanding of Pick databases was that they were typeless. Mongo isn't. There's a difference between being typeless and schemaless, and Mongo is a good mix for my usecases.
You don't understand Pick databases very well then. They supported types and could enforce them. Some Pick-style databases were weaker in this regard than others but there's nothing inherently typeless about the Pick database.
I wouldn't call Pick databases schema-less, either. Pick databases called their schema a dictionary. In a Pick database the dictionary is less strictly enforced than in a SQL database but it's not schema-less.
And before anyone goes off, yes, I know that Pick systems usually stored everything as a string. That was done for reasons that made sense in the 1970s, and because the Pick OS was implemented on several different hardware architectures.
That isn't the same as type-less though it looks that way at first glance. Although a number might be stored as a string of digits on disk the dictionary allowed for strict validation on the way in (Input CONVersions) and formatting on the way out (Output CONVersions). In my extensive experience with Pick OS I found that most programmers preferred doing that stuff in application code, the features of the dictionary were not much used, and as a result Pick code was harder to work with and maintain than necessary. I find the same thing when working with SQL databases -- instead of putting validation and enforcement in the database schema the rules are enforced in application code, usually in more than one place.