Ah, ok. Think I’m understanding a little better now.
For the db example I wouldn’t class that as anything to do with the browser, that’s more the API sending the collected information so any automation would be focused there.
For identifying cross browser specifics I tend to look in two main areas, functional and visual.
Functional: So can I complete the journey in different browsers? It may render slightly differently but all the functions, error messages, success messages, confirmation pop outs / ups / overlays etc. lead to the same output. You can do it. Any browser where you can’t do it is an issue. (usually IE or a variation on IE)
Visual: Does the page look similar enough not to be a problem for using, branding etc. Is the layout close enough.
These are both to identify if we need specific browser handling to replicate the user experience in different ones.
So for your list I’d say they could all apply depending on your context but like all testing I’d focus on what’s the highest risk to your users. If geolocation is important definitely check. If an accordion renders always open might not be much of an issue.
For Validation I’d say displaying the error message re already registered e.g. ‘Did you mean to sign in?’ would be a better check as it is highly unlikely a browser difference would let the same details register twice.
Without more context its really hard for me to be more specific on tests but I hope that helps in some small way?