When a Flatpak application is built, the build environment only has access the SDK and the SDK extensions, not to the host (I think you can technically give access to host but that would be wrong). Some of the SDKs are KDE, GNOME, Freedesktop and some extensions are Rust, C♯, Java. These provide the necessary stuff to build the application. For example, GNOME SDK has libraries and binaries common to GNOME applications. SDKs can build on each other, for example KDE and GNOME share Freedesktop SDK as their base. SDKs have versions and each application manifest declares the SDK and SDK version it needs. You don't have to declare the version but then it would default to master and that is only for development. SDKs can get updates but if a package declares GNOME 3.32 for its SDK, it will not update to 3.34 when it comes out, the updating is for bugfix kind of things. You can have multiple versions of the same SDK.
For other dependencies your application needs, you declare modules in the manifest. The sources to build the module can be version control repos, tarballs and other things. You can also specify the revision hash for repos and I think you have to specify the checksum for archive files. Flathub for example requires the manifests submitted to include the checksum or the revision hash if the source is a repo. I think the stable SDK, lack of access to host and source check mechanisms should mean the build is pretty much reproducible.
You can also "run" SDKs to get access to the base build environment or stop the build at a specific stage with the command line options to get the shell at a certain point. This I think should give the possibilities that guix environment gives.
You can also have multiple versions of an application. You can specify the version when run it from the command line or set the default version (technially branch) of the application so that when you start it from the launcher the desired version starts. Since all Flatpak files are stored in OSTree, which is like git for binaries, when you have multiple versions of an app, they share the common files through hard links and you store only one copy. Actually, since this tree is for all apps, if two different apps have the same file, they will share. It is guarenteed that they are actually the same with file hashes.
The package manifests are declarative and use JSON or YAML. Things like the environment variable, build options are declared there can be for the whole manifest or specific modules.
I don't really know what parametric packages are but as far as I understand Flatpak does not offer a similar functionality.
When the application starts, it has access to a runtime like KDE, GNOME, etc. that is declared in the manifest. This way multiple GNOME applications share the files.
Applications and runtimes can be installed for the whole system or for a specific user.
Application updates will not modify the applications files while it's running so there should not be brakage while updating.
Flatpak is not portable since it depends on Linux kernel features for sandboxing.
Lastly, I should note that Flatpak is specifically for applications, not system packages. For an atomic system, OSTree distributions like Fedora Silverblue can be useful. For example Silverblue is built with normal Fedora RPMs turned into a OSTree tree for the base system and uses Flatpak for applications. For stuff like development, pet containers are used so the user can have disposable containers that use traditional packages for development.