Ideally, Martinet would be re-implemented in a portable free software language such as Nushell or Python (more work is needed to see what Python offers for reading Windows-hosted applications including applications which have extant PowerShell modules). Switching the implementation language would increase the number of OSes on which Martinet can run and let Martinet access services across OSes which PowerShell can't reach (such as a service running only locally on a non-Windows system where PowerShell is unlikely to be installed).

Martinet:

• was written in PowerShell because PowerShell is far closer to a proper programming language than Power Automate and the like,
• was written in PowerShell because PowerShell was sufficiently powerful and widely deployed (no doubt due to the bias created by the University's Microsoft licensing),
• was written in PowerShell because PowerShell is extensible in ways Power Automate isn't. Power Automate et al are far more locked down for their connectivity to other applications and systems. Anyone who uses programs like Power Automate are likely to be less technical (Power Automate's chief audience are not programmers) and will have to wait for the proprietor (Microsoft, Amazon, etc.) to implement program/system API calls to make that program more powerful or capable. PowerShell already offers considerable connectivity to allow one to make foreign system API calls over common connections (XML-RPC over an encrypted connection, for instance).
• offers a simplified syntax which includes the ability to refer to objects using a wildcard syntax (and opportunities for other subtle but helpful improvements like this) which are not clearly available in Power Automate et al.
• is intended to be read-only whereas Power Automate et al are intended to be able to read and write to resources. Martinet contains no code that will modify or delete something, even accidentally, because Martinet is focused on inspecting current resources and pointing out inconsistencies with specified patterns. Also, Martinet is intended to run as a user that only has read access to the intended resources.
• offers access to arbitrary directory service object attributes. Power Automate's Active Directory commands don't currently offer a mechanism for referencing an AD object by its objectGUID (which makes knowing the object's name, sAMAccountName, or distinguished name irrelevant). Power Automate's Active Directory API seems to prefer referencing AD objects by the more brittle distinguished name which means that renaming an object or moving an object to another OU breaks the distinguished name.

It's not clear that Power Automate offers access to a folder's ACL comparable to what one can read via PowerShell. Power Automate can run PowerShell scripts, but if one needs to write PowerShell to do certain complex tasks what's the point of involving Power Automate at all?

Power Automate (as of 2025) seemingly targets automating desktop tasks — the kind of tasks receptionists might do every day, or the kinds of repetitive tasks which take in data from one source (say, a form submission or email) and add records to a target (such as a database). These are important jobs, to be sure, but these tasks center on modifying target resources. Martinet aims to never modify any resource.