/etc/rc.subr has run_rc_command() function used with base system and ports. The function contains this code: eval _override_command=\$${name}_program command=${_override_command:-$command} This code supposes that ${name} contents must have correct syntax for shell variable. This is wrong for our Ports Collection having plenty of ports with dash (-) in the ${name}. For such a port, ${name}_program expands to something like: part1-part2_program with non-existing (empty) $part1 variable. So, _override_command ends up with always-non-empty wrong value "-part2_program". Therefore, the value of ${command} set by port's startup script is always ignored due to code cited above and replaced with bad "-part2_program" string that break it all.
There is nothing that sets $name; each rc.d script must set it itself. To match documentation (rc.conf(5)) that states that shell variables can be set such as ⟨name⟩_nice, the name itself needs to be a valid shell variable name. So if an rc.d script sets name to a literal, it must be a valid shell variable name. If a script can be linked to multiple names for multiple instances of a service, this translates to a requirement on the administrator about which names they can use. Sanitization here may as well make things more confusing.
Dash is a problem also in base rc script for background fsck: /etc/rc.d/bgfsck name="background-fsck" I already posted about it 8 years ago without any reaction https://lists.freebsd.org/pipermail/freebsd-rc/2010-January/001814.html
The name= in etc/rc.d/bgfsck was finally fixed in 2014 in SVN r273013. This is present in 11.0 and newer but not in any 10.x or older versions.
(In reply to Jilles Tjoelker from comment #3) Thanks for the clarification. We are still using 10.4 so I didn't knew it was already fixed.
The base parts are fixed in 11.0 and newer, and older versions are unsupported.