Consider having constructs like the following i a CMAKE_TOOLCHAIN_FILE:
set(SOME_VAR “some_default” CACHE STRING “some text”)
What would be the drawback pitfall with it?
Will cache always work? ccmake?
Would option propagate correctly in add_subdirectory(…)? Also in all cases including top-levl CMakeLists.txt files induced by add_subdirectory()
Does order of option given on command-line matter?
BR /G
Somebody else feel free to jump in 
This is a helpful resource too, see Cache variables (https://cliutils.gitlab.io/modern-cmake/chapters/basics/variables.html).
Setting SOME_VAR like that will not always set the value in the case that the variable has already been set previously in CMake configuration or it has been passed via command line.
I do believe that variable (option) will populate to sub-directories since the toolchain file is included at the top level (typically on the command line) of the CMake project.
Because it is a cache variable, it will only set the value of SOME_VAR if it is not already set. It is not wrong to do so, but usually not the best approach. I tend to only need to set plain variables in toolchain files. These may be used to initialise other cache variables (e.g. setting CMAKE_CXX_FLAGS_INIT in the toolchain file, which is used to provide the initial value for the CMAKE_CXX_FLAGS cache variable).
Yes, there is no difference between the cmake and ccmake tools in this case.
The toolchain file is pulled in whenever a new language is enabled. It is as though include(myToolchainFile.cmake) is called at the relevant line. That means any variables it sets will remain visible in that directory scope and below. So yes, values will propagate down into add_subdirectory() calls. The top level project() command is usually where languages will be enabled, but it could also be in other places like where enable_language() is called or where project() is called against with additional LANGUAGES. The file will also be pulled in for try_compile() calls, but those are in separate test sub-builds off to the side and won’t affect variables in the main project.
Probably only if you have -U options mixed in with -D options, but I can’t be sure. You can always do some experiments to find out.