I don't like particularly this usage of top scope variables in the nagios module, but I've not found any other way to manage decently some parameters that are needed on the nagios servers and are used also by the target nodes.
So, given that some top scope variables are already used, I think that it would not be such a bad thing to define another top scope variable to manage parameters related to the nagios host.
Compared to your PR this would have 2 benefits:
- Allow to customize the host template (parameters) both for the nagios server and the target nodes (and not only the nagios server)
- Avoid the potential erratic behaviour I guessed in my earlier comment (related to the order Puppet applies the nagios::host resource on the Nagios server).

A smarter alternative could also be to try to use the params_lookup function instead of only brutal top scope variables, but I should explore it snce I never used params_lookup outside a class parameter.