Hi and welcome!

I don't know that I can comment fully on each of your articles, though feel free to ask about any specific points in them if there is anything in particular you'd like me to comment on.

That said, let's start by addressing the 4/5 issues you raised, at least from the perspective of Spectre as it operates today.

Inconsistent password restrictions lead to creating a state.

I assume this is referring to the fact that different websites may use different password policies, requiring us to potentially craft different types of passwords in order to pass website password validation checks.

While this is indeed a concern, Spectre handles this situation in a way that mostly resolves any practical concern. Spectre's default password type was engineered specifically to be high in entropy, legible/memorable in output, and conforming to most website password policies. You will be able to use this output in almost all cases.

Where a website's password policy does not permit you to use this type of password, Spectre allows you to select another from a small set of pre-determined templates. It is true that changing the password template means that some "state" needs to be recorded for this site. However, this really isn't the Achilles' heel it is made out to be. This type of state is recoverable metadata. Spectre's primary goal is to avoid unrecoverable secret state. This goal is still met even if the user records some metadata for some websites. The metadata can be stolen but does not compromise the user. The metadata may be lost and can be recovered by the user. It's fine.

Fixed or unchangeable passwords don't work, and other sensitive data such as credit card info, ID Numbers, etc is unstorable.

Spectre does allow you to store some additional information with your site. For instance, you may store a login name or attach a URL. It could theoretically store additional information. As previously indicated, storing information is not a problem for Spectre – it's just that this information in Spectre has the same issues that it does in any other password manager: it is encrypted state, and as such, it is vulnerable to loss, just like it is in any other store.

Password Iterations(having to change your password for some reason) requires creating a state.

Spectre deals with this situation through the use of a counter, and the counter is indeed state. As previously indicated with regards to password types, this state is recoverable metadata and keeping it doesn't create a real issue. Yes, it's state, and that is fine.

Remembering multiple usernames for multiple websites is difficult, leading to the creation of a state.

It is not the job of a password manager, let alone a stateless one, to remember user names. But that said, as previously indicated, Spectre can still store this information. What's more: it can generate random login identifiers which you might be able to use as a unique login name with the website, with some luck. These generated login names would be fully stateless.

Any solution that leads to the creation of a state requires syncing.

This is a loaded statement with many unspoken assumptions.
In reality, the statement is plainly false. A stateful solution does not require syncing, at all. It can (and it does) work just fine without syncing. If you personally feel syncing is required, that need is likely a complex need coming from the combination of several factors, at least one of them being a sense of anxiety about permanent access to recoverable state. Regardless, I'm not going to try to fully unpack the hidden assumptions in this statement.

Instead, I'll just state the obvious: Spectre is primarily an algorithm for generating non-recoverable secret tokens that make up your digital identity. It does a great job at this. Spectre is secondarily a hybrid solution which allows you to store recoverable metadata on sites for your convenience. This state can be synced, if desired. There is a standard file format to facilitate Spectre implementations across platforms and devices collaborating with each other on state. Even if you don't: Spectre works great even if you choose not to sync your state and either ignore it or manually maintain any separate Spectre instances.

With that out of the way, let's move on to your suggestions.

Let me begin with stating the obvious fact that it would absolutely be great if either there was less state to sync, or if the state that does exist was more "indestructible". I have taken great care to minimize the need for state and this continues to be an ongoing area of research for improvement, since I am equally committed to these goals as you appear to be. To that end, let's dive into your suggestions which I am certainly happy to have.

Inconsistent password restrictions lead to creating a state

You propose "a de-centralized database (possibly blockchain) that keeps a record of various website's abnormal password restrictions and requirements".
Firstly, let me point out that there are some efforts underway for documenting website password policies. For example, consider: https://github.com/apple/password-manager-resources
However, we can acknowledge that the web is vast and documenting its array of services will always be an "incomplete" project. It would be great if we could have some sort of universally accepted standard that websites can use to advertise their password policies, such as HTML attributes on their password fields, or a Sitemaps-style advertisement.
I am also continuing to look into improving Spectre's default password type for increased compatibility.

2, 3, & 4 all lead to the creation of a state.

I largely agree with your constraints. Very early versions of Master Password (the predecessor of Spectre) offered iCloud syncing but this was removed intentionally. I will not lock my users in to any walled garden, nor will I condone any cloud storage or third-party synchronization platform. Spectre's core principle is that the user should be in full and sole control of their data. Synchronization through any service tends to violate this core tenant.

There are of course ways to still transfer your data between devices. Spectre deliberately uses a well-defined and documented file format in order to facilitate this. Currently it allows users to export the data using whatever application on their phone they desire. iOS users can send it to their other devices using Airdrop, copy it and let it transfer through Universal Clipboard, or access it from On My iPhone or through iTunes Sync. It will even allow you to keep your Spectre user in a third-party application such as Dropbox and open it straight from there, if you so choose, allowing you to keep the metadata managed entirely by your third-party application.

A QR code is a good suggestion, too, of course. I will keep this in mind as Spectre evolves to the other platforms, though naturally we acknowledge that cameras aren't universally available on compute devices and QR codes might be easy to spy from afar.

I have also been thinking about some other mechanisms. Whatever I end up with however must be universally accessible, secure, and respect all of Spectre's core principles.

Thank you for your contributions and please feel free to continue the conversation!