Inconsistent behaviour when the sops configuration file isn't in (a parent of) the current working directory

The below is with sops 3.7.3 on Debian 12 on x86 (installed using the deb provided on the releases page).

Take a folder structure as follows

.
└── foo
    ├── hello.yaml
    └── .sops.yaml

where .sops.yaml contains (trivial) GCP KMS creation rules, e.g.

creation_rules:
  - path_regex: .+
    gcp_kms: [REDACTED]
    encrypted_regex: .+

and hello.yaml contains

hello: world

Note the following.

1. Encryption fails.

$ sops -e foo/hello.yaml
config file not found and no keys provided through command line options

2. Creating an encrypted file interactively fails.

$ sops foo/goodbye.yaml
config file not found and no keys provided through command line options

3. Encrypting the file from within foo works.

$ cd foo
$ sops -e hello.yaml > hello.enc.yaml

4. Creating a new encrypted file from within foo works.

$ cd foo
$ sops goodbye.yaml

5. Decrypting the encrypted file... works!

$ sops -d foo/hello.enc.yaml

That is, the behaviour of 5 is inconsistent with 1 and 2. For decryption, sops appears to walk from the file towards the root in search of configuration; for encryption, it doesn't.

Is this the intended design or is the inconsistency a minor mistake?

Reproduce the four encryption and decryption commands from the report, comparing configuration lookup when run from the repository root and from foo. Trace the command entry points that load .sops.yaml and add regression coverage for matching configuration discovery during encryption, interactive creation, and decryption.