Meteor 1.4 Settings API: alert thresholds frozen at startup after moving off --settings files

Context

Since Meteor 1.4 replaced the deprecated --settings file loading with the enhanced Settings API, Meteor.settings is loaded once at server startup and is immutable at runtime. Attempts to assign new values to it silently have no effect until the server restarts.

Goal

I want to drive alerting thresholds (for example, error-rate or queue-depth limits) from configuration without restarting the server, so that a tuned threshold takes effect immediately instead of leaving the app firing alerts against stale values.

Uncertainty

The documentation points toward environment variables or external configuration services for dynamic behavior, but environment variables also require a restart, and there is no built-in runtime reload for settings. This leaves a design gap: either alerts keep reading frozen startup values and generate noise after thresholds should have changed, or configuration must move to an external store with its own consistency concerns.

Questions

1. Is keeping Meteor.settings immutable the intended permanent design, or is a runtime reload API on the roadmap?

2. For dynamic alert thresholds, is an external configuration service (or a Mongo-backed config collection) the recommended pattern over settings?

3. Does this immutability guarantee still hold unchanged in current Meteor releases, or has newer behavior superseded the 1.4 semantics?