Should primitive_types::H160 be bytes20?
Also should ink_primitives::types::AccountId be bytes32?

You mean if primitive_types::H160 should be mapped to bytes20 for the Solidity metadata? Is there no native "H160" type in Solidity, for contract addresses?

You mean if primitive_types::H160 should be mapped to bytes20 for the Solidity metadata

Yes

Is there no native "H160" type in Solidity, for contract addresses?

That would be address (the current implementation), the question is more about the ink! side. Is this a "safe" mapping? Does primitive_types::H160 (in the signature of an ink! constructor/message/event) always represent an address or is it just a 20 bytes hash?

On the Solidity side it's trivial to convert between address <-> bytes20 <-> uint160. I'm just wondering if its "sound" to assume primitive_types::H160 always represents an address on the ink! side.

That's a good point. There's nothing keeping people from just using the type as a general purpose [u8; 20] without any association to an address.

Hmm, maybe we should after all introduce an Environment::Address type instead of using H160 implicitly for that. That would give you more clarity on the semantic interpretation.

Do I understand you right that you mean in the sense of us providing a type ink_primitives::Byte = u8 for developers?

So if e.g. someone wants to ensure the following return value gets mapped to bytes2 in the Solidity metadata:

#[ink(message)]
fn get(&self) -> [Byte; 2]

Exactly

For the existing AccountId = [u8;32], would that stay the same? And then would the mapping to Solidity be something like: AccountId == uint8[32].

Or would it become: AccountId = [Byte; 32] == bytes32?

One other thought: if an RLP encoded ink! message takes an AccountId(32) as a parameter, should we give any linting warnings or simply represent it as bytes32 (or similar)?

Or would it become: AccountId = [Byte; 32] == bytes32?

Yes ink_primitives::types::AccountId should be bytes32. There's no need to convert it to AccountId = [Byte; 32] though, the top level wrapper type already makes it unambigious

if an RLP encoded ink! message takes an AccountId(32) as a parameter, should we give any linting warnings or simply represent it as bytes32 (or similar)?

I think we just represent it as bytes32 with no warnings since Solidity has no equivalent elementary/primitive type and the user/dev can't do anything about it.

Edit: Also I believe it's common for Solidity contracts to represent foreign (cross-chain) addresses as bytes<N> especially in cross-chain messaging protocols.

For a consistent naming throughout.

I'm not sure about this one, this line is for the <artifact_name>.abi file. See image below:

With this suggested change, this becomes

Can you explain in a comment somewhere how developers can influence which text lands in NatSpec and which in DevDoc?

So for Solidity, NatSpec (https://docs.soliditylang.org/en/latest/natspec-format.html) has a concept of "tags" (e.g. @dev and @notice) that represent the target audience (e.g. developer or user) for specific lines in docs e.g.

/// @notice An NFT
/// @dev Inherits OpenZepplin ERC721 implementation

ink!/Rust don't really have a "native" equivalent to this, and I'm not even sure we need one because explorers seem to show both AFAICT. So I think we just treat ink!/Rust comments as DevDoc for now, and ignore (leave empty) the UserDoc fields.