Force rebuild of a minion's state?

TL;DR

I have begun controlling all my virtual machines using Saltstack. I have set up two separate environments, init and base, for installing the minion on a freshly deployed VM and ongoing configuration management, respectively. Having successfully deployed a minion, it adheres to the states from BOTH environments! I don't want that. It should only be managed according to the base environment.

Why does it use both environments and how do I force it to not care about the init environment anymore, after initial deployment?

Having deployed a new VM I use salt-ssh to set up repositories, install the salt minion and fire it up. After that I use salt to manage my VMs. So for every new VM I do (once)

salt-ssh -i 'anewhost' state.apply

and after that I do/cron does

salt '*' state.apply

The configuration of my file roots are the only content of my master's configuration file:

file_roots:
  base:
    - /srv/salt/base
  init:
    - /srv/salt/init

To make a VM a minion I use a roster file. /etc/salt/roster, where every block looks like this:

anewhost:
  host: anewhost.mydomain.tld
  user: root
  passwd: rootpw
  minion_opts:
    environment: init

The idea is

• when I do state.apply using salt-ssh, the state is constructed starting at /srv/salt/init/top.sls
• when I do state.apply using salt, the state is constructed starting at /srv/salt/base/top.sls

What happens is, that salt-ssh behaves exactly like expected, but salt creates some unified abomination that actually contains both states, described by init and base.

Apparently salt remembers the init environment and pulls it in, no matter what I do. How do I make it forget about the init environment?

Edit: Quickfix

I fixed it by augmenting my init states to append environment: base to /etc/salt/minion. This actually makes the minion ignore the init environment. But why did it honor it in the first place? Isn't the idea behind environments to make salt do different things?