So is the behavior of the optional="true" tag that if the field form is left empty for that parameter then it will not be passed to the tool?
Optional is enforced at the UI level; a wrapper can choose to handle optional parameters differently.
I am wondering if a more sophisticated behavior on the UI side of things for the "optional" tag would still allow for recording that the parameter is using the default value for the version of that tool but not actually pass that parameter on the command line in case it influences the behavior of the tool? Thinking of parameters that should have a default value but whose actual presence on the command line changes what happens. Though, I guess this could be done by simply deleting the default value in the optional parameter has one?
Maybe if the optional tag enabled the parameter itself to be toggled on/off (grayed out/regular text)? This way a block of advanced parameters could be enabled without requiring that they all be passed to the tool (or deleting all their values if they are marked optional).
There are two issues to consider: (1) Whether the UI is friendly when a tool has many parameters. Clearly, there are improvements to be made, but Galaxy makes it relatively easy to ignore parameters that aren't of interest. A novel UI approach might try to make it easier to hide unwanted parameters from view or selectively set certain parameters. (2) Whether optional parameters should be passed to the wrapper. IMHO, there's no reason not to make all user input available to the wrapper. A tool that doesn't produce the same output when (a) parameter values are not specified and (b) default parameter values are specified is buggy and should be fixed. Best, J.