How do their APIs compare?

These two projects aren't really comparable as "APIs" in the same sense — they serve very different purposes and one barely has a public API surface at all in the traditional sense. Let me lay out what's actually visible in the retrieved data for each.

klocman/bulk-crap-uninstaller — not a library API, but a CLI + internal application surface

BCU is a Windows desktop uninstaller app. It doesn't expose a public library API for consumers; the closest things to an "API" are:

• The console interface (BCU-console), a command-line surface with subcommands like uninstall, export, and list, plus switches (/Q, /U, /V, /J=<Level>) documented in [source/BCU-console/Program.cs:L28-L57]. This is a shell-facing API (arguments in, exit codes out), not a code API.
• Internal domain classes like ApplicationUninstallerFactory.GetUninstallerEntries(...), used both by the console [source/BCU-console/Program.cs:L360-L367] and presumably the GUI, which take a progress-reporting callback and return IList<ApplicationUninstallerEntry>.
• Functional/business logic classes such as AppUninstaller (uninstall orchestration, process-killing logic in GetRelatedProcessIds [source/BulkCrapUninstaller/Functions/AppUninstaller.cs:L134-L175], junk cleanup in SearchForAndRemoveProgramFilesJunk [source/BulkCrapUninstaller/Functions/AppUninstaller.cs:L448-L470]) and UninstallerListConfigurator.GenerateEquivalentFilter() [source/BulkCrapUninstaller/Functions/ApplicationList/UninstallerListConfigurator.cs:L73-L120], which build up filter rules for the app list UI.

These are all internal, app-specific, imperative, side-effecting APIs (they touch the registry, processes, filesystem) intended to be consumed only within the BCU application itself — there's no NuGet package or public contract for external developers.

Also worth noting: RepoPilot's import graph analysis reports 0 files parsed / 0 internal imports for this repo, meaning the architecture signal (grade C, 50/100) is essentially uninformative here — it couldn't build a real picture of the internal API surface or coupling. So take "how the API is structured" claims about BCU with that caveat: the computed architecture signal is empty, and everything above comes from directly reading the retrieved source snippets, not a full picture of the codebase.

louthy/language-ext — a genuine, general-purpose functional programming library API

By contrast, language-ext is designed from the ground up as a reusable API for other .NET codebases, following functional-programming and typeclass-style conventions:

• Typeclass-style interfaces (Eq<A>, Hashable<A>) implemented by small structs, e.g. EqBool.Equals(bool a, bool b) [LanguageExt.Core/Class Instances/Eq/EqBool.cs:L18-L19], EqString.Equals(string a, string b) with both ordinal [LanguageExt.Core/Class Instances/Eq/EqString.cs:L19-L20] and culture-aware [LanguageExt.Core/Class Instances/Eq/EqString.cs:L173-L174] variants, and EqMap<K,V>.Equals(...) [LanguageExt.Core/Class Instances/Eq/EqMap.cs:L15-L16].
• Generic, composable hashing instances like HashableIterable<HashA, A> [LanguageExt.Core/Class Instances/Hashable/HashableIterable.cs:L9-L11], HashableEnumerable<HashA, A> [LanguageExt.Core/Class Instances/Hashable/HashableEnumerable.cs:L9-L11], and HashablePatch<EqA, A> [LanguageExt.Core/Class Instances/Hashable/HashablePatch.cs:L10], all parameterized by other typeclass instances — a hallmark of language-ext's "class instance" pattern for ad-hoc polymorphism in C#.

This is a pure, side-effect-free, strongly-typed, generic API meant for public consumption as a library dependency, contrasted sharply with BCU's imperative, OS-interacting internal methods.

Summary of the