It's sort of sounds like two duplicates - since both the answers that you linked actually explain things. I can't tell if map or filter should specifically say that they preserver order; they don't rely on any previous state or any other state (these are stateless operations) so it is implied that they preserve order as far as I can see. I see it the other way around, if they don't preserver order - that should be explicitly mentioned in the docs; if it not obvious from the name of the operation.
For example Stream.generate is not obvious to me if it generated an ordered stream; thus this is said in the documentation of it:
Returns an infinite sequential unordered stream where each element is generated by the provided Supplier.
sorted and unordered on the other hand are pretty obvious (IMO) to change order, at least when you put these in - you are explicitly saying that you do not care about the order. unordered btw will not do any randomizations on purpose to satisfy this, you can read more here.
There are two orders in general: processing order and encounter order.
You can think about encounter order as processing from left to right (imagine you have a List or an array). So if you have a pipeline that does not change order - elements will be fed to the Collector (or any other terminal operation) as seen from left to right. Well not all terminal operations are like this. One obvious difference is forEach and forEachOrdered; or a Collectors.toSet - which does not need to preserver the initial order at all. Or let's take findAny as the terminal operation - obviously you don't care which element you want, so why bother feeding the findAny in an exact order in the first place?
Processing order on the other hand has no defined order - especially visible for parallel processing obviously. So even if your pipeline is parallel (and elements are processed with absolutely no guarantee of any order), they will still be fed to the terminal operation in order - if such an order is needed for that terminal operation.
