[BUG] pillar.get doesn't respect saltenv minion setting

Description
I expect that when I perform a pillar data lookup, then it will use the default or specified saltenv, but I find it selects some random environment instead. For example, my pillar data has this:

saltenv: {{ saltenv }}

so I expect that I should be able to say salt-call pillar.get saltenv and get back base (the default), but instead I get one of the other environments.

Setup
Here's the relevant excerpt from /etc/salt/master:

file_roots:
  base:
  - /srv/salt

  jon:
  - /srv/salt-environments/jon/states

  eli:
  - /srv/salt-environments/eli/states

  __env__:
  - /srv/salt

pillar_roots:
  base:
  - /srv/pillar

  jon:
  - /srv/salt-environments/jon/pillar

  eli:
  - /srv/salt-environments/eli/pillar

  __env__:
  - /srv/pillar

And here's my minion config which specifies the default saltenv and also that we should use the same env for the pillar data:

saltenv: base
pillarenv_from_saltenv: True

Here's my pillar top.sls:

{ saltenv }}:
  '*':
   - match: glob
   - ignore_missing: True
   - common

and to test I put this in /srv/pillar/common.sls:

saltenv: {{ saltenv }}

Steps to Reproduce the behavior
(Include debug logs if possible and relevant)

Expected behavior
I expect that making a call like salt-call pillar.get saltenv will give me base, but it doesn't:

$ salt-call pillar.get saltenv
local:
    jon
$ salt-call pillar.get saltenv pillarenv=base
local:
    base

So basically, my default pillarenv is base, but calling pillar.get with no arguments is returning pillar data from the jon environment.

If this was only happening at the command line then it wouldn't be a big deal, but there are a bunch of places in my sls state files where I do things like this:

{% if salt['pillar.get']('yum:stable') %}
configure stable yum repos:
  ...
{% endif %}

So what's happening now is that I run a state.apply like this:

salt-call state.apply saltenv=base pillarenv=base

but the call to salt['pillar.get']('yum:stable') returns pillar data from the jon environment.

This seems like a bug. I realize that I could specify the saltenv and/or pillarenv parameters to pillar.get, but I didn't think I had to, since the call to state.apply specifies the environment we're using. Plus it would be a huge pain (and make things brittle) to need to pass those parameters every time we do a pillar.get.

Versions Report
Both the minion and master are on version 3000.1:

Salt Version:
           Salt: 3000.1
 
Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 1.5
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
         Jinja2: 2.8
        libgit2: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.6.2
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.5 (default, Aug  7 2019, 00:51:29)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 15.3.0
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.1.4
 
System Versions:
           dist: centos 7.7.1908 Core
         locale: UTF-8
        machine: x86_64
        release: 4.4.131-1.el7.centos.x86_64
         system: Linux
        version: CentOS Linux 7.7.1908 Core

Please let me know if there's any other data or examples that I can provide.

No source file or test is named. Start by reproducing the issue with salt-call pillar.get saltenv and salt-call state.apply saltenv=base pillarenv=base, then trace the pillar.get and state.apply entry points; done means the lookup uses the configured or explicitly selected environment instead of jon.