I've always known that the IV should be 128 bits, because that's the block size of AES, regardless of the key.
The IV depends on the mode of operation. It may well be that the block mode of operation specifies to use the block size, but this is not a given. For instance, AES-GCM defaults to 96 bits.
For CTR mode it is rather common to supply an IV, but in reality that consists of a nonce and a starting counter value; you could have implementations / protocols that only expect the nonce as input, which would then be smaller than 128 bits.
However, I just saw one vendor advertising AES-256 with a 256 bit IV.
Not many modes support that, so I'm wondering how they accomplished that. AES-GCM does support it, but at the expense of additional calculations. Furthermore, it doesn't increase security at all. It doesn't make much sense for AES-CBC mode either, as the second ciphertext block will be the IV, i.e. the effective IV would still be 128 bits.
The other more likely option is that they use Rijndael with a block size of 256 bits. In that case it is not AES (which is Rijndael with a block size of 128 bits and only 3 key sizes with the default number of rounds configured). In that case they really don't know what they are doing.
Is there any point to that? Does a 'double' IV bring additional guarantees? For example, reducing the probability of having the same IV with the same key?
No generally it doesn't bring any benefits. As it is hard to use AES in such a way that the block size of 128 bits isn't a limiting factor (e.g. when it comes to processing a huge amount of blocks), I don't see how a larger IV would alleviate that issue.
Will it even work with standard AES implementations, or they'll reject it? The Java implementation rejects it, for example.
Again, it depends on the mode; GCM may grog it. Java simply keeps to the standards, I've not seen Oracle deviate all that much yet.
Effectively, it adds another block of plaintext to throw away, but if it works, does it have negative effects (apart from having one more block to process)
Again, depends on the mode and how it is configured.
Or is it just a marketing mistake...
I might well be a marketing mistake. That's pretty likely actually. An engineering mistake (AES vs Rijndael) is also likely. It could however also be snake oil although you should not attribute to malice that which is adequately explained by stupidity.
However, definitive statements can only be made after more detailed analysis, and for that we need the source. I'd have them explain it to you.
