PDEP-16: Consistent missing value handling
Note: this is only a draft, partial proposal. It already lists the main points of the proposal at a high level, but of course we need to add a lot of the details and specifically about backwards compatibility and how we can move towards the end goal (I think those last aspects will actually require the most discussion eventually, the devil is in the details here ;)). 

But, I thought to already open this PR to start the discussion on those main high-level points of the proposal (we can already discuss those and see if there is agreement about that), and to have a reference for this NA proposal (since it has come up in a lot of other tangentially related discussions as well), and also to push myself to actually write up those other sections as well ;)

A summary of all (potentially breaking) behaviour changes that I am aware of can be found here: https://github.com/pandas-dev/pandas/issues/58243#issuecomment-2053656616

**Abstract**

This proposal aims to unify the missing value handling across all dtypes:

- All data types support missing values and use `pd.NA` exclusively as the user-facing missing value indicator.
- All data types implement consistent missing value "semantics" corresponding to the current nullable dtypes using `pd.NA`

This proposal tries to provide a high level way forward, and is not meant to address all implementation details (i.e. all dtypes should follow the above principles, but we don't need to decide in this PDEP for every single dtype how this is exactly achieved)

cc @pandas-dev/pandas-core @pandas-dev/pandas-triage
This pull request is stale because it has been open for thirty days with no activity. Please [update](https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#updating-your-pull-request) and respond to this comment if you're still interested in working on this. @jorisvandenbossche @phofl are you planning to continue work on this? If not, should we just close and pass the torch to somebody else? Another option is to vote on the part already described here, and let other issues or PDEPs discuss specific details if needed?

Keeping this open in its stale status seems to be harming the project more than being of any value. I would personally like to revive this discussion (although I haven't fully caught up with all other ongoing discussions from the last days to know how that would potentially impact this PDEP). 

I can try to fill out the details (of what is currently summarized) in the coming weeks. But also if someone else is interested in helping to move this forward, that is certainly welcome.