Yes, I may have interpreted the comments or docs incorrectly but I thought that was the point of enabling the /conf.d/ config loading like logstash does.
My goal is to maintain multiple configs in /conf.d/* one per team that has rule requirements without having 1 massive rule file. I have different teams dependent on audit rules like compliance, security and app teams. The plan was to have a conf file per team where they can configure their own rules. I'm not sure what happens for performance when I tell auditbeat to watch a file that doesn't exist but if I were to maintain 1 large config file, I'll be looking for hundreds of files that don't exist due to the various app teams that would have their own file watches. If I were to do this same thing with auditd it would work because any file or path that didn't already exist would just error out when trying to add that specific rule.
It would also be nice if there was an option to dump the list of current rules that are running, since the logs showed that rules were deleted and some where added, but I had no idea what was actually loaded after startup, similar to how you can run auditctl -l to dump the currently loaded rules. I could probably comb thorough the output of auditbeat to see what rules were added and if they were eventually deleted to build that list, but a local get status command would have been helpful or occasional printing them with a debug option.