bug(developer): compiler should report as an error or warning using `index` with stores that have different numbers of characters

[sewhite]

Describe the bug

I would expect this code below to either fail to compile, or compile with a warning. The two stores have different numbers of characters. I thought Developer used to do that.

store(&NAME) 'Community test'
begin Unicode > use(main)

group(main) using keys
store(vowels) 'aeiou'
store(acuted) U+00E1 U+00E9 U+00ED U+00F3 U+00FA U+00FD

"'" + any(vowels) >  index(acuted,2)

This report would have been very useful for a user who entered ordinary vowels in one string then decomposed accented vowels in the other string, expecting the index command to give the accented vowel after a deadkey.

https://community.software.sil.org/t/the-deadkeys-do-not-seem-work-for-accented-vowels/8399/2

Reproduce the bug

No response

Expected behavior

No response

Related issues

No response

Keyman apps

• [ ] Keyman for Android
• [ ] Keyman for iPhone and iPad
• [ ] Keyman for Linux
• [ ] Keyman for macOS
• [ ] Keyman for Windows
• [ ] Keyman Developer
• [ ] KeymanWeb
• [ ] Other - give details at bottom of form

Keyman version

16.0.145

Operating system

Windows 11 Home 22H2

Device

Windows laptop

Target application

No response

Browser

No response

Keyboard name

No response

Keyboard version

No response

Language name

No response

Additional context

No response

[mcdurdin]

There is a warning produced if the index() store is shorter than the any() store, but not vice-versa. Version 17 gives the following warning in that situation:

warn KM02085: The store referenced in index() is shorter than the store referenced in any()

We could conceivably produce a hint for the converse, where the store in any() is shorter than the store in index(), but we wouldn't want it to be a warning or an error, because it's a legitimate use of the stores.

[mcdurdin]

Moving this to triage for 18.0.