Clarify when plugin settings are being populated (#79710)

docs/docsite/rst/dev_guide/developing_plugins.rst

@@ -75,7 +75,17 @@ To define configurable options for your plugin, describe them in the ``DOCUMENTA
         type: boolean/float/integer/list/none/path/pathlist/pathspec/string/tmppath
         version_added: X.x
 
-To access the configuration settings in your plugin, use ``self.get_option(<option_name>)``. For the plugin types (such as 'become', 'cache', 'callback', 'cliconf', 'connection', 'httpapi', 'inventory', 'lookup', 'netconf', 'shell', and 'vars') that support embedded documentation, the controller pre-populates the settings. If you need to populate settings explicitly, use a ``self.set_options()`` call.
+To access the configuration settings in your plugin, use ``self.get_option(<option_name>)``. 
+Some plugin types hande this differently:
+
+* Become, callback, connection and shell plugins are guaranteed to have the engine call ``set_options()``. 
+* Lookup plugins always require you to handle it in the ``run()`` method.
+* Inventory plugins are done automatically if you use the ``base _read_config_file()`` method. If not, you must use ``self.get_option(<option_name>)``.
+* Cache plugins do it on load.
+* Cliconf, httpapi and netconf plugins indirectly piggy back on connection plugins.
+* Vars plugin settings are populated when first accessed (using the ``self.get_option()`` or ``self.get_options()`` method.
+
+If you need to populate settings explicitly, use a ``self.set_options()`` call.
 
 Configuration sources follow the precedence rules for values in Ansible. When there are multiple values from the same category, the value defined last takes precedence. For example, in the above configuration block, if both ``name_of_ansible_var`` and ``name_of_second_var`` are defined, the value of the ``option_name`` option will be the value of ``name_of_second_var``. Refer to :ref:`general_precedence_rules` for further information.