It is possible to mix versions from adjacent major MongoDB server releases (for example: 3.6 and 4.0) for the purposes of upgrading, but in general a cluster should have consistent versions. Successive server versions are expected to add new features (additional data types, authentication mechanisms, protocol improvements, new commands, ...) that do not necessarily interoperate with every prior release. Upgrade steps and compatibility details are included in the release notes in the MongoDB documentation.
As part of the upgrade process for MongoDB 3.4+ there is now an intentional step of setting a Feature Compatibility Version (FCV) to toggle features that persist incompatible data changes while an upgrade is in progress. If you started with a MongoDB 4.0 deployment (rather than upgrading from a prior version), new 4.0 features will be enabled by default.
I highly recommend matching your
mongo shell and command line tools with the version of your MongoDB server, and checking the compatibility for your driver.
I cannot add a 3.4 shard into a 4.0 cluster
Correct. If the 3.4 deployment is currently an independent replica set, it would have to be upgraded to MongoDB 3.6 and then upgraded to MongoDB 4.0 before adding to a 4.0 sharded cluster.
If you were starting with a 3.4 sharded cluster, all components of the cluster would have to be upgraded to MongoDB 3.6 (including setting FCV to 3.6) before continuing with the upgrade to MongoDB 4.0.
Reversely I cannot add a 4.0 shard into a 3.6 cluster
In theory you could downgrade a 4.0 replica set if you want to add it to a 3.6 cluster, but this is more challenging than upgrading. Any backwards incompatible data that has been persisted would have to be removed or updated.